S/4HANA Extensibility Concept Details: Restricted ABAP

In this “S/4HANA Extensibility Concept Details” blog series I want to elaborate details for specific topics. I want to start with the concept of “Restricted ABAP”.

Motivation

The official SAP white paper on S/4 Extensibility (see link to the official white paper and my personal summary in (S/4HANA Extensibility – The new White Paper) introduces two pillars of S/4HANA Extensibility: the side-by-side extensibility with SAP HANA Cloud Platform (HCP) and the ABAP-based in-app extensibility. ABAP-based in-app extensibility comes into the play when for reasons of performance, transactional security or strong data coupling side-by-side extension must be ruled out. (For the non-ABAP-based parts of S/4, for example the HCM solution (aka SucccessFactors), the same pattern applies, as explained, for example in the OpenSAP Course „Extending SAP Products with SAP HANA Cloud Platform“, https://open.sap.com/courses/hanacloud3-1).

The rich feature set of the ABAP language and the vast amount of enterprise-ready functionality in the ABAP basis is without any doubt one of the major success factors for SAP. By adding custom code to the SAP core, customers and partners can adopt the SAP standard software to the business needs of the particular companies. On the “dark” side of the ABAP story, ABAP developers can easily cause major damage to the SAP business processes (in terms of integrity, security, and performance) when used in an inappropriate way. In addition custom code in many SAP system is highly interwoven with the SAP core, which makes the upgrade process expensive and error-prone.

Looking at the S/4HANA cloud edition, it is quite clear that a cloud provider (this is SAP) cannot grant access to the full ABAP functionality to a customer or partner developer.

For this reason SAP decided to provide a restricted ABAP version which can be operated in a safe way in a cloud environment. The set of allowed ABAP language statements is restricted since custom code could otherwise easily break compatibility and upgradability and also functional correctness of SAP processes (example: deleting an entry in a SAP table, creating parallel processes, dynamic function call, …).

The restricted ABAP has two targets:

• De-couple custom code from the SAP core by enforcing the exclusive use of white-listed SAP APIs
• Minimize the risk of damages to the system or the data integrity/security

Concept

The concept of restricted ABAP is built of two pillars: the restricted syntax and the white-listing check.

• Restricted syntax: only a well-defined part of the ABAP syntax tree is allowed in the restricted ABAP version. For example code generation and dynamic programming is not allowed. The restricted syntax check works as a whitelist/blacklist on the ABAP syntax tree. It allows or blocks complete ABAP statements or branches of statements in the syntax tree.
• White-listing check: only white-listed SAP APIs (for example white-listed classes and CDS views) can be used. The syntax check analyses the used SAP objects and checks if they are white-listed.

The restricted syntax and white-listing check is included into the ABAP syntax check (and also into ABAP code completion). So it is independent of the used editor. The following figure shows this in detail: When the restricted mode is switched on, the central ABAP syntax check, which is used by the editor in the ABAP workbench, in Eclipse, and in the web-based ABAP editor, performs the restricted syntax and white-listing check. As the syntax check is part of the ABAP activation, an ABAP source that fails the check, cannot be activated and executed.

Restricted ABAP in the S/4HANA Public Cloud Edition

The first consumer of the restricted ABAP is the S/4HANA public cloud edition.

S/4HANA provides means for key users and partners to customize and enhance the applications’ business logic. Key users/partners can use ABAP for implementing business logic extensions, but in the public cloud deployment model not all ABAP features can or should be made available. In the first step, logic extensions are done via SAP business add-ins (BAdIs), because BAdIs provide a clear contract between the core application and the implementing party.

You can find a web-based ABAP editor to implement custom logic in the Custom Fields and Logic Fiori app. The app will appear in your Fiori Launchpad when the Extensibility role is assigned to your user. The following screenshot shows the app. While designed for the cloud edition, the Custom Fields and Logic Fiori app is also available in the S/4HANA on-premise version. If you want to see the app in action, check out the video.

On the frontend, the Custom Fields and Logic Fiori app provides a modern web-based text editor that supports the following features:

• Syntax highlighting, syntax check, code completion (shown in the screenshot), text formatting (“pretty printing”)
• Split-screen editor that shows the draft code, and (optionally) the published code, and the code of the example implementation
• Access to documentation of the enhancement option (BAdI)
• Draft (sandboxing) and published version
• Embedded test support for the draft implementation and the published version
• Details, if you are familiar with SAP BAdIs: the editor completely manages the creation of the enhancement implementation and the implementing class (and hides the technical details from the user). As a user, you only have to implement the method (“code snippet”) that implements the custom logic.

On the backend the editor operates on ABAP classes with the restricted ABAP check. Supported language features are:

• Basic expressions, control and flow statements, variables and internal tables,
• String, math, data & time operations, … ),
• Read and write access to the interface of the BAdI
• Read and write access to white-listed SAP APIs (classes)
• Read access (full SQL select support) to white-listed SAP CDS views.

The following ABAP features are not allowed to ensure the robustness, security and data consistency target:

• any DB operation except selects from released views, for example the commit work statement is not allowed (which obviously makes no sense and is dangerous in a BAdI)
• access to files and other I/O commands
• creating new tasks (parallel processing)
• dynamic programming
• code generation
• To simplify the syntax, obsolete ABAP statements are removed from the syntax

You can find the complete list of allowed statements in the documentation.

Future Use Cases

Customer extensibility in S/4HANA public cloud edition is only the first use case for the restricted ABAP concept. Further use cases are described in the following blogs:

Restricted ABAP for SAP Cloud Platform ABAP Environment

Restricted ABAP and SAP S/4HANA On-Premise