Skip to Content
Product Information

S/4HANA In-App Extensibility – End of Classical Extensions?

As we all know, with S/4HANA comes the new Extensibility framework and all we are hearing now is In-App and Side-by-Side extensions for the custom code management. And with that a lot questions like what all can i do using In-App extensibility? when should i go for In-app extensions? when Side-by-side? and should i not go for classical extensions at all?? And i too am looking for the answers , so thought of  sharing my understanding on the topic and open for additions and your experiences on the same. So, lets start…

What we have been doing so far (Classical Extensions)

First, let’s see the level of changes that we have been making so far in the traditions world ( SAP ERP Business Suite)

As we know, SAP has always provided the flexibility to adjust the standard objects to cater to the business process needs and to achieve the same SAP has provided extension points at different levels and layers in the form of

  • Customer Exits
    • Function module exit
    • Screen Exit
    • Menu Exit
  • Business Transaction Events (BTE)
  • Business Add-ins (BADIs)
  • Table Enhancements ( Append structures)

Modify standard objects using Access keys, User Exits and so on as depicted in pic below.

 

S/4HANA Extensibility Framework

Now, lets see what we have got with S/4HANA Extensibility framework i.e In-App extensibility. So, with In-App Extensibility we have multiple tools available to extend application at different layers like

  • UI extensibility – Hide, move, add fields, change labels
  • Field extensibility – Custom fields & Logic
  • Table extensibility – Custom objects
  • Business logic extensibility (Restricted ABAP – Check this blog for different shades of ABAP)
  • Analytics extensibility
  • Forms & Email extensibility

To read more on these in-app tools read this wonderful blog from Thomas Schneider

Note: Classical extensions are still possible in S/4HANA On-premise version.

Why New Extensibility Approach?

As we all know, with all the custom developments we do, to enhance the business process, comes the effort to check and adjust the same whenever SAP  delivers new versions of application during upgrade or support packs and this effort get higher and higher with increasing customization.

Also, with Quarterly (for cloud) innovation release cycle it become more import to address the impact and adjustment requirement. So, as to minimize the impact of upgrades or support packs on custom code in-app extensions were introduced.In-app custom extensions contain no source code modifications, are loosely coupled, use only whitelisted APIs and extension points, and are fully compliant with zero downtime principles.

Mapping Old to New 

The question now is, how does the traditional extension ways maps with the new framework? and that is a very relevant one.. isn’t it?

and that would somewhat look like as depicted below:

Table below shows 2 prominent examples for old and new enhancements:

Business object

Old enhancement option

New enhancement option

Sales order User exit MV45AFZZ
BAdIs in enhancement spot ES_SD_SLS_EXTEND
(for example, sales header modification or sales document check before a save)
Purchase order BAdI ME_PROCESS_PO_CUST
BAdIs in enhancement spot ES_MMPUR_PROCESS_PO_CLOUD
(for example, purchase order header modification or final purchase order check before a save)


Is Everything Covered?

Next thing that comes to mind is…yes,your are guessing it right… can all the extensions be mapped to new options ? do we need to have classical extensions anymore? and the answer to that is a big NO,  at least for the time being..

The in-app extensions are possible only for applications for which business context are available. The number of available business contexts were very small and number is increasing with every release of S/4HANA. Current availability trend is like below.

So, what is covered then? How can we find what is available?

SAP has provided standard transaction code “SFCD_REGISTRY” (Extensibility Registry) .. It is like a single stop shop for in-app extensibility usage in different ABAP objects. It gives you all the information like:

  • Which all Apps/OData can be extended with custom fields
  • GUI apps which are supported by In-App extensibility
  • CDS Views which can be extended with it
  • SOAP Services ,FM & IDOCs which are covered by In-App Extensibility

We can start here to check the feasibility of required scenario via in-app extensibility.

It is also very important to know that standard ABAP can’t be used  fully in the web editor, used to implement custom logic, It’s restricted ABAP and goes by the word “ABAP for key users”. 

Supported features include

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

Not allowed to ensure the robustness, security and data consistency target:

  • any DB operation except selects from released views, for eg. the commit work statement is not allowed
  • 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

Complete list of available statements of ABAP for key users can be checked here.

SAP has provided standard report “ABAP_DOCU_VERSION_WHITELIST” to list all language elements, which are allowed, based on language version. For e.g. to check the available elements list for “ABAP for key users”. Select language version 2 on selection screen and execute and we have the list of whitelisted objects for version 2.Check this blog for details.

How the In-app extensions transported across landscape systems

Another important question, which we normally forgets, is the movement of In-App extensions across systems.And the process is somewhat different in this case

Pre-requisite for In-app extensibility tools usage is “Adaptation Transport Organizer(ATO) Setup” . Here we configure the local package to which the in-app extensions will be locked. We also define the sandbox package and the in-app extension prefix here (which gets append to all the in-app extension we create )as shown below.

Next to assign the custom package, which we want to carry our extensions across systems via transport, using SAP Fiori app “Configure Software packages” and finally registering the required extended objects from local package to the custom package using Fiori app “Register Extensions for Transport”

Check this blog for detailed process.

Recommendation:

If multiple options are available choose in from the following in the sequence shown:
  1. New BAdIs for SAP S/4HANA
  2. Explicit enhancement options, user or system exits, or application-specific enhancement
  3. frameworks
  4. Explicit enhancement options
  5. Modifications of SAP code
  6. Clone and adoption of SAP code

Summary

To summarize, I will quote the statement from Karl Kessler

It is important to note that in-ap extensions are not a replacement for ABAP development. Custom ABAP development plays an important role in the context of SAP S/4HANA, and SAP has made significant investments in a new ABAP programming model, based on core data services, to support SAP Fiori development for applications such as SAP S/4HANA. In general, these two roles — key users and ABAP developers — must work closely together to combine the best of both approaches and provide comprehensive business solutions tailored to organizational needs.

 

Keep Learning Keep Sharing!!

Vijay

3 Comments
You must be Logged on to comment or reply to a post.
  • Dear Vijay.
    Thank you for you nice blog.

    One question. What is your idea for the the best option for deploying a development in S/4HANA Single Tenant?
    Deploy the application in the SCP or S/4?

    Custom applications that are not related to ERP, it makes sense to deploy to SCP. Simple reports for purchases, sales, financial, using CDS views or RAP, if your customer does not have a roadmap for the S/4HANA Cloud Multi-Tenant, you are only increasing complexity and maintenance, in addition to considering network latency.

    What are your thoughts?

    Best regards,
    Guilherme

    • Thanks Guilherme!

      On your question, i am no expert , but let me try and share my thought. The choice of deployment should depend on the scenario, to name few:

      • Future roadmap (Mutli tenant plan if any)
      • SAP and Non SAP system and application interacting with S/4
      • Depth of customization being done in the core
      • etc..

      So, as you mentioned, if customer has no plan for Multi-tenant at all, we need to assess other things as well, for example, if I have lot of non sap apps that we are going to have , if we have  many custom development done in the single tenant which will require considerable effort to adjust or verify the custom code with every SAP innovation (which are very frequent with S/4) etc..

      In such cases , it is better to keep the s/4 core clean from custom code and build and deploy the same in SCP.

      Again, SCP involves cost with it, along with the benefits it brings. So, we need to weigh, whats the best option looking at all the angles.

      Even if we deploy apps in S/4 , we should try and use Cloud coding guidelines to minimize the upgrade impact on custom code. So, we should follow the In-app extensibility approach for extension ( wherever possible), use Whitelisted API’s for integration and we should be good irrespective of where we are deploying the apps …

      Thanks

      Vijay