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…

Also Read: SAP S/4HANA Financial Accounting Certification Preparation Guide

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
  
• Analytics extensibility
  
• Forms & Email extensibility

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.

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”

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