Restricted ABAP and SAP S/4HANA On-Premise
In the blog posts S/4HANA Extensibility Concept Details: Restricted ABAP and Restricted ABAP for SAP Cloud Platform ABAP Environment , I introduced the concept of restricted ABAP, or naming it correctly: ABAP language versions, and discussed the usage of the concept in SAP S/4HANA Cloud and in SAP Cloud Platform ABAP Environment. In this blog post, I want to add some thoughts on the concept of restricted ABAP in the context of SAP S/4HANA on-premise.
Before we go to on-premise, let us recap the facts for Cloud:
- for SAP S/4HANA Cloud, the ABAP language version “ABAP for Key Users” is enforced by the environment (Web-based ABAP editor).
- for SAP Cloud Platform ABAP Environment, the ABAP language version “ABAP for SAP Coud Platform” is enforced by the environment
In an on-premise system, you have the freedom to choose one of the following options:
- Option 1: Use the ABAP language version for all or some development objects. In this case, the restrictions of the ABAP language version are checked as part of the syntax check. If there are violations, the object cannot be activated.
- Option 2: Check the restrictions of the ABAP language version with ABAP Test Cockpit (ATC). In this case, an object that violates the limitations of a language version can be activated. After running the ATC checks, an error is shown.
If you decide to use a restricted ABAP language version in on-premise (option 1), you can set the ABAP language version by object, using the Eclipse-based ABAP Development Tools (ADT) as shown in the following figure:
Figure: Set the ABAP language version in the Eclipse-based ABAP Development Tools (ADT) for a development object
Note that the ABAP language version can only be set and changed individually for ABAP source code objects like classes, interfaces and function groups.
If you want to use an ABAP language version on a larger scale, you can set the default ABAP language version for a package in the package editor. When creating development objects in this package, they will be created with the selected ABAP language version.
Figure: Set the default ABAP language version in the Eclipse-based ABAP Development Tools (ADT) for a package
The boundary conditions of this setting are:
- Only newly created objects get the ABAP language version of the package.
- When the ABAP language version of a package is changed, the ABAP language version of the objects in the package remain the same as before.
- When an already existing object is moved into a package with a different ABAP language version, the ABAP language version of the object is not changed.
- If the ABAP language version of the package is not supported by type of object to be created, object creation will fail.
- If an object type does not support the ABAP language version concept at all, it will be created independent of the ABAP language version of the package.
- Some objects do not support the change of the language version after creation (e.g.ABAP dictionary objects). Thus, you must be careful to create these objects in the correct package.
If you want use the strategy to check the compliance of an ABAP language version with the ABAP Test Cockpit (option 2), you can do this for example using the Eclipse-based version of the ABAP test cockpit. In the Project Explorer, select an object or a package, open the context menu and choose Run As -> ABAP Test Cockpit With …. In the subsequent dialog, enter “SAP_CP_READINESS_REMOTE”.
SAP_CP_READINESS_REMOTE is a Global Code Inspector (CI) check variant that checks the scope of ABAP language version ABAP for Cloud Development.
The following picture shows the results of the ATC check:
- “Syntax error in restricted language scope”: an ABAP statement is used that is forbidden in ABAP for SAP Cloud Platform
- “Usage of not released API”: an API is used that is not allowed in ABAP for SAP Cloud Platform ABAP
Figure: Results of the “Cloud readiness” ATC check
If you want to check your code for ABAP language version ABAP for Key Users, you need to create your own check variant.
Before closing, I would like to point out in which cases the use of restricted ABAP can be helpful in on-premise systems:
- You plan to move some custom applications to SAP Cloud Platform ABAP Environment
- You plan to move to SAP S/4HANA Cloud completely, or we plan to carve out a specific part of your SAP system and move it to SAP S/4HANA Cloud.
- You do not have plans to move to SAP S/4HANA Cloud in the near future, but want to empower your business departments to use key user tools to make their extensions, such as custom fields, custom analytics, small logic enhancements, on their own, instead of requesting it from a central IT department or provider.
- You do not have plans to move to SAP S/4HANA Cloud in the near future, but want to reduce the adaptation and test effort that comes along with SAP updates, and thus want to enforce custom code to use released, stable SAP APIs.
For use case 1 (move custom applications to SAP Cloud Platform ABAP Environment), I recommend reading the blog How to check your custom ABAP code for SAP Cloud Platform ABAP Environment. It explains in detail how to use ABAP Test Cockpit (ATC), the SAP Fiori App Custom Code Migration, and the new ATC Cloud readiness checks.
… to be continued with more details on use cases 2, 3, and 4.
Thanks Thomas Schneider!! Very useful.
One question, Under custom logic InApp BADI , ABAP for Key users is enforced. But we can change the supported language version to achieve more functionalities in on-premise. But is it recommended? will it have any impact during upgrade?
I would not recommend this. If you are using the Web-based ABAP editor under Custom Fields and Logic, you should not change the language version. But what you can do:
I call option 2 a "breakout" scenario. Option 2 has the advantage, that you use the language version ABAP for Key Users (which means that you enforce use of released APIs in general), but you have some "breakouts" where you still use non-released APIs. Over time, you could try to reduce the breakouts once a suitable SAP API is released.
Very helpful blog, please can you explain how I release a class that is written using "Standard ABAP Unicode)" for use in another class that is using ABAP language version "ABAP for Key Users".
At the moment I just get a syntax error when I try to use the standard class for the key user class.
We have S4HANA ON PREMISE 2020 01.
Vijay, who asked the initial question above, helpfully wrote a blog that explains how to release a custom class for Key-User extensibility:
Note that you do this through the ABAP Development Tools (ADT) in Eclipse, not in SE80.
However I'm not sure you need to do this. Let me reply on Vijay's question...
In ADT go to the "Properies", "API State" tab. IN this tab, you can create a new release contract. See the documentation here: Setting the API Release State - SAP Help Portal
Hi Thomas Schneider
So we don't want to change the ABAP version of the BAdI implementation class if using Key-User extensibility. Presumably because having done so, Key User extensibility would no longer work with that BAdI implementation.
But what perhaps hasn't been made clear, is that on-prem customers don't have to use the Key User tools to implement the new cloud BAdIs.
You can just implement them using SE19, or using ADT. If you use ADT, then the implementation class is created with version Standard ABAP by default. In SE19 it creates it with the Key User version, but you can change it.
Correct me if I'm wrong!
Correct. If you use the key user tool, the ABAP language version "ABAP for key users" is enforced and must not be changed manually. If you use SE19 or ADT, Standard ABAP is the default.
Just when I thought I understood it, I've found a further complexity.
In transaction SCFD_REGISTRY, BAdIs are marked as available On Premise, in Cloud or both.
For example enhancement spot ES_SD_SLS_EXTEND is intended to replace VOFM routines.
Some of the BAdIs in it, like SD_SLS_COPY_RQMT_HEAD_SLS, are marked as available in Cloud only.
However in the same system (op 2020 release) I was able to find this BAdI in ADT and create an implementation for it without any issues.
So is this field just for information, and has perhaps just got out of date in this example?
Or would the 'Cloud only' setting somehow prevent the BAdI implementation from running in my on- premise system?
I think I can now partly answer my own question.
The availability setting in SCFD_REGISTRY controls the availability of the BAdI within Key User app Custom Fields and Logic.
So in my on-prem system there's no option to implement SD_SLS_COPY_RQMT_HEAD_SLS through the app, but nothing stopping me from implementing it through ADT or SE19.
My doubt then, is can we safely ignore this flag or not, if the BAdI exists on prem, but the 'availability' is cloud-only?
Is it just that the BAdI previously did only exist in the cloud, and someone forgot to update the flag when it was added to on-prem?
you are right, SCFD_REGISTRY controls the content available in the Key User app Custom Fields and Logic.
I cannot tell why application development set the Cloud-only flag. In some cases, business processes run slightly different in Cloud and on on-premise (the on-premise scope is normally broader than the Cloud scope), or the new BAdI is only called in a Fiori app that is not released in on-premise.
So technically nobody is stopping you from implementing the BAdI with ADT or SE19 but if application development sets the cloud-only flag, I would recommend to use the respective "old" extension technique.
Very helpful. Thanks Thomas Schneider
Thomas Schneider, thanks for the helpful Blog!
One question: From which NetWeaver version on can the ABAP Language option be set on individual objects and on packages?
On our 7.50 System this is greyed out in ADT, only on our S/4HANA System I can change this.
The full functionality that I described in this blog is available as of S/4HANA 2019. The language version ABAP for key users was introduced earlier, but definitely not with NetWeaver 7.50.
I have 2 questions to ask
1) In on-premise, it works the same way as in the Cloud, given that you are on the latest version. You can get the tree via the function New -> Repository tree in the Eclipse-based ABAP development tools.
2) There are 2 versions of Restricted ABAP:
In addition, I recommend the ATC check variant SAP_CP_READINESS (_REMOTE) to check for non-allowed statements. This gives you the best and fastest overview on the non-allowed statements you are really using.
Thomas Schneider May be I did not understand you correctly. We are on S4HANA 1909 and when I login via ADT I see no options in the project explorer to see the list of Released Objects. In the below image, the system 1 is an S4HANA onPrem system 1909 and system 2 is a ABAP Cloud Trial.
Can you please try on your on-premise system:
@Thomas Schneider Thanks a lot for the quick response. I assume, I cant take this as a complete list of released objects. As there is not much for Classes and function modules in the list. If we plan to enforce developers to follow restricted ABAP on a OnPrem system, they wont be able to do much. I tried to use a basic BAPI call in the onPrem System and it showed my syntax errors.
Same Error is displayed when i run the ATC variant “SAP_CP_READINESS”
I agree that the list of released object is still small in SAP S/4HANA 2019. The plan to enforce developers to follow restricted ABAP on a OnPrem system is challenging, and for the time being I would recommend to go for a hybrid approach:
Does this make sense for you?
We are planning to use whitelisted objects (class, fm, DD object) for ABAP development & performed the ATC check using SAP_CP_READINESS to find the violations.
However, finding the whitelist object for code remediation is becoming a difficult activity.
Manually scanning the released list from ADT for suitable fit is a tedious activity.
Can you please advise?
SAP is currently maintaining the so-called successor information. In future there will be a clear successor information.
For example for the line:
you will get the error message:
Unfortunately this information is only available in the latest system. However, you can use the Custom Code Migration app (See: ABAP custom code analysis using SAP Business Technology Platform | SAP Blogs ) to do remote checks. In the future, the Custom Code Migration app will contain also the successor information so that you can do a remote check to your "old" systems.
Thanks Thomas for quick response,
We have executed the ATC check - SAP_CP_READINESS & plan to remediate the custom program using whitelisted APIs (Currently on S4H1909)
Which S4H release ATC will provide the successor information?
We are not the latest release, hence successor information is not available to us. Please suggest if successor information is available on the SAP portal or through OSS.
Thanks & Regards
A list of successors is published upfront in SAP note 3088062 Identifying local APIs for S/4HANA Cloud: https://launchpad.support.sap.com/#/notes/3088062 -> Excel attachment
I have checked note. It is giving error - "You are not entitled to access SAP Note/KBA 3088062."
Also checked using SNOTE -" Error getting URL of Note 0003088062 : Note incomp lete"
Both options not working
Thanks & Regards
I use I_PRODUCT instated of MARA but I am getting Whitelisted violation in I_PRODUCT CDS view also.
Please Let me know how could I remove this violation.
Which S/4 release?
thanks for this and your other great blogs around this topic.
It seems to me, neither of the restricted ABAP options are a great fit for extensions on-prem?
I was looking at ABAP for Cloud, and I see only 44 CDS views are released for customer use. This makes sense for Cloud where the S/4HANA data model doesn't exist, so only views relating to generic concepts like country and currency are available. I see SAP_CP_READINESS_REMOTE also would limit CDS view access to this selection.
But when developing on-prem, clearly we may wish to access business data directly through a SELECT rather than through an unnecessary oData call. For Key User ABAP, it looks like 4260 CDS views are released, which fits with this idea.
However as you explained in your recent blog, Key User ABAP is more restrictive than ABAP for Cloud regarding syntax, as it was really only intended for writing code snippets.
It seems to me like the least bad option may be to choose standard ABAP, and to build a custom ATC check based on SAP_CP_READINESS_REMOTE, but with the full list of 4260 CDS views pasted in.
Or maybe a more suitable ABAP version will come with the planned developer (on-stack) extensibility?
Would be keen to get your thoughts - am I missing something?
you are right for the on-premise releases that are out in the market. Here, only object from SAP_BASIS are released for ABAP for Cloud Development. The situation changes with SAP S/4HANA 2021 on-premise. In this version, S/4HANA development releases many objects for ABAP for Cloud Development. There will be a broader rollout on the options of using the language version ABAP for Cloud Development. I will definitely comment on this in my blog posts.
For the time being, the situation when working with the language version ABAP for Cloud Development is as follows:
Best regards, Thomas
Thanks Thomas. Will be interesting to see how it moves forwards in the 2021 release.
Extremely intriguing , great job and a debt of gratitude is in order for sharing a decent blog.Monkey
Thanks for the helpful blog. I tried to use one of my local CDS view as a table type in the method, (lt_local type table of 'cds_name')
(This CDS is an abstract entity which is generated by the system when I created local service consumption model to fetch the on-prem data)
but that is not working, showing the following error:
Use of CDS Entity 'Entity_name' is not permitted.
Also, there are a lot of errors while using data elements (and hence I have to use data type instead of data element).
Use of data element 'dataelement_name' is not permitted.
Please suggest something.
If you decide to use a restricted ABAP language version in on-premise:
We wonder why it's not possible to call function modules with a standard destination (SM59 type 3 - ABAP Connection) (remote in another system) with language version "ABAP for Cloud" even though you are using an on-premise system ( results in Dump when it gets executed - RFC_ILLEGAL_CALL_ON_SAPCP - Reason: "NOT_A_DYNAMIC_DESTINATION" ).
If we execute exactly the same code in a class with language version "ABAP Standard" it works (I guess you can only use destinations created by CL_RFC_DESTINATION_PROVIDER based on cloud dest. names in code with language version "ABAP for Cloud").
This is a problem, because we have to duplicated exact the same code (in two classes with different language versions).
Could you tell us something about that? We haven't found any information about it.
in the cloud we only allow the usage of RFC destinations for system-to-system integration and not e.g. Destination NONE. In addition we need to protect our internal cloud landscape from customer access and need content separation between the destinations for SAP and customer integrations, see e.g. Overview of Communication Management | SAP Help Portal.
These concepts are not yet available in on-premise.
Currently the only option is to move all RFC outbound calls in wrappers outside language version 5, e.g. via a custom developed released API. Even if you would create a dynamic destination by other means, there are runtime checks in the Kernel that make it impossible to use destinations of type 3 in language version 5 coding.
We are working on a better solution for the S/4HANA 2022 release.
ABAP Platform Integration & Connectivity
Thanks for the quick answer. That helps.