Restricted ABAP and SAP S/4HANA On-Premise

[ThomasSchneider]

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:

1. You plan to move some custom applications to SAP Cloud Platform ABAP Environment


2. 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.


3. 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.


4. 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.