Skip to Content
Technical Articles

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.

Picture1.png

 

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.

Screenshot.png

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 may follow (to be contiued …).

13 Comments
You must be Logged on to comment or reply to a post.
  • Hi Thomas,

    Could you please explain here, what is the difference between frontend and backend ? As I was assuming that since it is a web based editor, everything is frontend only.

    Frontend -> Custom fields and logic app
    Backend -> Any other editor ? Or you mean abap environment only. if abap environment then why restricted ? it should be full version.

    Regards,

    Tejas

  • Hello @Thomas, Many Thanks for explanation.

    Could you please give some preview on Transport mechanism of the implemented logic? is Cloud edition also support CTS + / CTS?

    If you give some pictorial view of Transport movement in cloud, it would be really helpful.

    Regards,
    Krish

  • Excellent post. I find the concept innovative to keep the benefits of both the world – on premise extension viz a viz cloud offering.

    The success of this concept depends on how restricting SAP wants to be to enable customer innovation.

    Regards, Yogesh Malpani

     

  • @thomas.schneider

    Very nicely written blog, I have one query, you have mentioned

    Syntax highlighting, syntax check, code completion (shown in the screenshot), text formatting (“pretty printing”)

    Can you please let me know what are the keyboard shorts-cuts to do all these operations or any SAP reference where all these information is mentioned.

    Regards

    Ankesh Jindal

  • Dear Thomas,

    This is an excellent post. thanks for that. was wondering if there is a comprehensive document where one can find what is allowed and what is not in terms of restricted ABAP with some scenario’s. Example scenarios:

    1. Earlier, we were using the table TVARVC for maintaining parameters and restrict the enhancements to make them work for certain plants/company codes. can we do the same in cloud BADI’s in restricted ABAP environment?
    2. How can we call BAPI’s or FM’s inside restricted ABAP?

    would highly appreciate if you can show some guidance in these lines. thanks a lot

     

    • Thank you for your comment. The first thing I want to mention is that, since I wrote this blog, a second very important use case for restricted ABAP came into life: the SAP Cloud Platform ABAP Environment (aka Steampunk). There are many blogs about SAP Cloud Platform ABAP Environment out, but I never wrote a blog which deals in particular with the restricted ABAP for the SAP Cloud Platform ABAP Environment. Unfortunately I never found the time, but let me add 2 links to the documentation: https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/index.htm?file=abenabap_versions.htm -> This link takes you directly to the documentation of the ABAP language version for SAP Cloud Platform ABAP Environment.

      But I think you are asking about the ABAP language version for key users, which is available in Fiori/Web-based ABAP editor in S/4HANA Cloud?

      on 1) this depends on the concrete BAdI. Some Cloud BAdIs provide filter parameters , in particular BAdIs in FIN (per company code). In this case, you can create one implementation per filter.

      on 2) No. Applications are adviced to provide wrapper classes around their FMs or BAPIs and release them for ABAP for key user, if they should be used.

      In general the key words that are available for ABAP for key users are documented here: https://help.sap.com/viewer/0f69f8fb28ac4bf48d2b57b9637e81fa/2002.500/en-US/dd39f11e977b41b49a5421399f4850f5.html

       

       

       

      • Hi Thomas,

        Thanks for your reply back and the information shared. Just wanted to ask one additional input based on your reply on point 2.

        on 2) No. Applications are adviced to provide wrapper classes around their FMs or BAPIs and release them for ABAP for key user, if they should be used.

        Excellent idea. I think we can manage to write a wrapper class around the FM’s or BAPI’s or may be create custom CDS views. but, just wondering how do the following

        1. How do we whitelist the custom wrapper classes we would create (BAPI’s/FMs’)?
        2. How do we add the custom CDS views to the “released CDS view” list ? The transaction SCFD_REGISTRY doesn’t allow us to do so. Please advise

        Thanks

        Srini B

        • How do we whitelist the custom wrapper classes we would create (BAPI’s/FMs’)?

          This is possible for S/4HANA on-premise only. In this case, you an release you class in the ADT editor, properties tab, API state. The same is for CDS views. There is no need to do this in SCFD_REGISTRY.

          But this is possible in S/4HANA on-premise only. In S/4HANA Cloud, only SAP application development can provide a wrapper and release it.

           

          • Thank you Thomas for your response.

            will check this and get back to you. i am assuming the solution you provided is applicable for S/4HANA hosted on cloud like AWS or Azure.

            Best Regards,

            Srini B

          • Hi Thomas – worked out the solution you told. Perfect! this is exactly what i was looking for and i cant thank you enough. thank you very much. I look forward to see you blogs more on Extensibility, restricted ABAP and API’s usage in restricted ABAP if any in future. thanks again. you are of great help as always.

             

            Best Regards,

            Srini B

          • Hello Srinivas,

            I got the same requirement to access TVARVC table when create custom logic.

            May I know how you resolve this?

            Regards, Kevin

          • Hi Kevin,

            here are steps that you can try.

            1. Use the “custom business object” extensibility App and create the structure of the table like TVARVC and may be whatever is required in terms of usage like Params table.
            2. Bring the OData of this “Custom Business Object”  to Web IDE and test it. Deploy the same as SAPUI5 Fiori App.
            3. create this as tile in Fiori LaunchPad for people to make entries in this table.
            4. you can release your custom CDS view in the ADT editor, properties tab, API state as suggested by Thomas.
            5. you are now ready to use this CDS view as param table in Restricted ABAP

            I hope this helps. Also, please do remember that this works for On-prem and on-prem hosted on cloud.

            Thanks

            Srini B