New ABAP Platform Extensibility Options in 2021
In 2021, new extensibility options were added to the ABAP platform, increasing the power of creating extensions in the Cloud. In this blog post, I want to give an overview on the available extensibility options and also tell you which options are available where.
In the following figure, you can find an overview on the extensibility options that are available now:
Starting point of my blog is the classic extensibility option of the ABAP platform. Available on the market since the first SAP releases, it is a cornerstone of SAP´s market success for SAP R/3, SAP ERP, and SAP S/4HANA on-premise. Classic extensibility includes a long list of extensions techniques that were developed and leveraged by application development over time. Classical extensibility is very powerful, because it enables you to extend SAP applications (from extension includes extending database tables, code extensions via user exits, class extensions, BAdIs, … UI extensions and many more) and to use (call) all kind of SAP code (BAPIs, function modules, classes, …). Even modifications of SAP code are part of the toolbox of classic extensibility. On the other hand, classic extensions are difficult to maintain and cause major effort for regression testing and adaptation when SAP upgrades and updates are applied.
In the document Extensibility Guide for SAP S/4HANA Cloud, extended edition, extension techniques of the classic extensibility are classified as critical for the lifecycle management and operations (“red”) or less critical (“yellow”). For example, modifications are classified as “red” extension techniques, while implementations for non-released BAdIs or classic user exits are classified as yellow. The document was written for SAP S/4HANA Cloud, extended edition, but it can also be used as guidance for on-premise. “Red” extension techniques should only be used is there is no viable alternative (in SAP S/4HANA Cloud, extended edition they are forbidden), while yellow extension techniques may be still tolerated.
Extensibility Options with SAP S/4HANA
Together with SAP S/4HANA, new extension options were rolled out that allow lifecycle-save, cloud-ready extensibility:
- In-app Key User extensibility
- Side-by-Side Extensibility on the SAP BTP
Key user extensibility is available since 2015 for S/4HANA Cloud & on-premise. It is designed for specific use cases (often the so-called last mile adaptations). The key user extensibility tools are hiding the underlying complexity from the user. It is designed for experts in business departments or implementation consultant with a high process knowledge. It uses local released, lifecycle-stable APIs and extension points only. Therefore, key user extensions can be considered as clean/green code.
Since 2014, side-by-side extensibility on SAP BTP (at that time named SAP HANA Cloud Platform) is available. You can use developer or no-code/low code tools and various technology platforms to build loosely coupled extensions using remote released and lifecycle-stable APIs and events for integrating with SAP S/4HANA. With side-by-side extensibility you can leverage skills and resources of your workforce, for example in Java or integration development, and the services and resources that are available on SAP BTP. With side-by-side extensibility, you can flexibly call-off resources for the respective runtime environment in SAP BTP. Resources can be scaled without impact on the core system. This means you can “keep the core clean” also with the aspects of workload and performance.
In 2018, SAP added ABAP to the SAP BTP, called SAP BTP ABAP Environment or by its project name: Steampunk. Steampunk comes with Eclipse-based ABAP Developer Tools and the ABAP language version ABAP for Cloud Development. In this language version, only released APIs and objects (such as data types) of the ABAP platform can be consumed. Remote released APIs and events are used for integrating with SAP S/4HANA (same as for other side-by-side extensions).
This was the story my colleagues and I were telling in numerous sessions, blogs, mails, … (see SAP S/4HANA Extensibility: A Learning Journey for a collection of resources). But now lets look at the great new options that have been introduced in 2021!
What did change in 2021 – for SAP S/4HANA Cloud?
The ABAP development environment was made available in SAP S/4HANA Cloud named the SAP S/4HANA Cloud ABAP Environment (aka Embedded Steampunk). This option is available as of 2108 for early adopter customers. In the figure and in the documentation of SAP S/4HANA Cloud, you can find it under the name Developer Extensibility. This option closes the gap that existed between the in-app key user extensibility option and the side-by-side extensibility option. It is based on the same language version (ABAP for Cloud Development) as Steampunk, but in the embedded option, you have direct access to local released APIs and extension points of SAP S/4HANA. A nice overview on the evolution can be found in Steampunk is going all-in.
What did change in 2021 – for SAP S/4HANA on-premise?
In my blog Restricted ABAP and SAP S/4HANA On-Premise I discussed the use of the ABAP language version ABAP for Cloud Development in on-premise. Using this language version in on-premise helps you to create clean/green code already in your on premise system to make your extension more update-save and prepare for a move into the Cloud. Up to now, the use of the ABAP language version ABAP for Cloud Development in on-premise had the big disadvantage that only APIs from the ABAP platform were released and could therefore be used, but no APIs and extension points from the SAP S/4HANA layer. This changed in the version 2021. In this version SAP S/4HANA application development released about 2.500 CDS views, 200 enhancement spots (with BAdIs) and numerous objects such as data types, domains, authorization objects, … . In addition, 11 RAP business object interfaces (behavior definitions) are released. RAP business object interfaces are the successor of classical BAdIs in the world of the RESTful ABAP programming model (RAP) . The scope of released APIs in 2021 is of course not comparable with the huge amount of functionality that you can access in classic extensibility – but is a starting point for your clean code that can grow over time.
What did change in 2021 – for SAP and partner extensions built on SAP BTP ABAP Environment?
Partners (or SAP) can create their (side-by-side) extension on SAP BTP ABAP Environment and provide it to many customers. To be able to do this in a cost-efficient manner, multi-tenancy for the SAP BTP ABAP Environment was introduced. Since release 2108, you as a partner can enable your partner solution on SAP BTP ABAP Environment for extensibility and let your customers extend them using key user tools in a multitenancy environment. This is described in my blog post Extending the Extension – Key User Extensibility for SAP BTP ABAP Environment.
The following figures shows which extensibility option is available for which product.
All in all, 2021 will be another turning point for extensibility of ABAP-based solutions in the Cloud. From the viewpoint of the extensibility options, the picture is now complete. Now the crucial point is to increase the amount of released APIs and extension points and to close the remaining gaps in the toolsets for developer and key user extensibility.
What is meant with "extension point"? ENHANCMENT-POINTs / ENHANCEMENT-SECTIONs?
I use it here in a much broader scope: in classic extensibility these can be enhancement points and options, BAdIs, class extensions, user exits, and some application specific extension techniques.
In developer / key user extensibility for code extensions, only BAdis are allowed, and planned for the future RAP extensibility.
Thanks for the info.
"Class extensions" are also the pre- and post-methods that are available for any class?
Thomas Schneider , good to see some honest comments here:
"The scope of released APIs in 2021 is of course not comparable with the huge amount of functionality that you can access in classic extensibility – but is a starting point for your clean code that can grow over time"
I'm implementing S4 HANA 2020, and still having to use old CMOD exits due to the absolute lack of options. And SAP itself is still releasing notes recommending the implementation of old SD user exits in support notes (see note 3046057).
While I admire the effort of SAP of going to the cloud, this is still a drop in the ocean of legacy code. Developers will still face the challenge of doing a ABAP RESTful app one day and going back to old legacy the other day. We can't replicate (and don't have enough APIs and extensions) to do everything "side-by-side".
Fair statement. But every journey starts with the first step. For the S/4HANA Cloud scope, SAP already offers a good offering for lifecycle-stable extensibility (the existing S/4HANA Cloud customers prove that), but for the on-premise scope there is still a long way to go.
Is embedded Steampunk already available in S/4HANA on prem 2021 ? To work already on eSteampunk on prem , do I only have to switch the ABAP language version to "ABAP for cloud development" ? or will I have to migrate these "clean code" objects later to eSteampunk ?
Steampunk/Embedded Steampunk has several aspects:
You can immediately start with 1) and 2) in SAP S/4HANA on-premise 2021. The RAP programming model and the ADT tools are now ready for mass usage.
On 3) you can use the language version to "ABAP for cloud development", but as mentioned in the blog and in the previous comments, the list of released APIs is still limited. So you can start but you cannot do a complete change by now. And there is another technical limitation. You can switch the language version for ABAP code objects (classes, interfaces, ...) but not for DDIC/CDS objects. So you can use the language version to "ABAP for cloud development" for new objects, but not change it afterwards. This is another limitation that must be removed in future releases to make full benefit of the concept of Embedded Steampunk in on-premise.
Within the use of custom logic there is below BADI:
How to add transient fields to a business object ( for example for object Sales: Billing document)? With the customf fields app we are only allowed to add persistent fields. So where to add those transient fields?
Thanks in advance!
this is an excellent example. In the key user app Custom Fields and Logic, you can only add persistent custom fields. But if you create a field of type code list, or currency, some transient fields (ie. description fields) are added automatically.
Excellent and information blog post Thomas Schneider. I wonder if you could use your expertise to help clarify a few things for me please?
Thanks in advance,
Does embedded steampunk support the creation of OData services using the @OData.publish: true annotation? Or must RAP be used? This is for a read-only scenario.
OData.publish is retired. You always create a service definition & binding. With this concept you get a much better flexibility (explicite definition of entities you want to expose, type of OData services: v2/v4, UI or API service, ...).
Thanks Thomas, good to know.
However I notice if we use Key-User extensibility app F1866A ‘Custom CDS Views’, and choose to create an API, then it produces a CDS view with @OData.publish: true. So I guess that's still a valid option to produce a read-only API?
Yes this is true. the key user tools are still using @OData.publish: true. The will be migrated in the future. But you asked for Embedded Steampunk. Here @OData.publish: true is no longer supported.
Please use service definition/services binding instead.
Perfect thanks for confirming. My customer's currently using S/4H on-prem, but we want to future-proof our developments as far as possible.
The URL for Deveoper Extensibility in your blog is not working. Maybe you can update this?
I am (desperately) looking for some documentation on developer extensibility, namely a list of internal APIs or extension points, to check what is possible.
I have a specific customer case where some modifications of an SD order item are impossible in key user extensibility, and they would like to know if this can be achieve by using developer extensibility (and moving to the new 3SL with steampunk of course).
Can you provide some Links or documentation on the internal APIs we would have with developer extensibility?
Hello @Thomas Schneider, and thanks for this update on new S/4HANA Cloud extension possibilities.
In terms of SAP's strategy going forward, I have a question: I can only imagine that SAP is likely to publish far more "new" Events within the existing framework of S/4HANA (Cloud) Enterprise Event Enablement, than it is likely to publish new BAdIs/Enhancement Spots (I could even imagine a ratio of up to 10-20 new Events for every 1 new BAdI released)?
If it is indeed correct that far more "new" Events will be published in the future (in line with SAP's move towards full EDA support) than new BAdIs, doesn't this suggest that Side-by-Side Extensibility remains our most 'complete' extension solution in the decades to come?
Thanks, Cameron HUNT
This is a good question. IMHO a pure count of events versus BADIs does not make much sense, because the granularity might be very different.
But I can answer your question whether "Side-by-Side Extensibility remains the most 'complete' extension solution". This is not the case. In principle SAP application should provide remote APIs and events and local APIs and BADIs. Of course, this is a general guidance, at a certain point in time their may be some differences. Or their may be also use cases where remote/local APIs do not make sense. For example, their may be some BADI use cases where in event simply does not make sense (or vice versa).
Thanks for your response Thomas Schneider. I think you touch on the point I was trying to make with your statement that "their may be some BADI use cases where in event simply does not make sense...".
This seems to suggest, as I suspect, that even if a company changes to the very latest offering of SAP, Developer Extensibility, if there is no BAdI, there is no extension. So even if companies have Developer Extensibility/eSteampunk (and I doubt this is a simple lift-and-shift), they will in any case often be required to put in place full Side-by-Side Extensibility for at least 1 use case.
And once you have Side-by-Side Extensibility, including a mandatory instance of BTP Event Mesh, why bother with Developer Extensibility at all ? Why not switch to full EDA (as is happening elsewhere at pace) and forget about the latest SAP offering which in any case cannot respond to all future use cases (whereas we can anticipate more and more Events being published by SAP, regardless of their "granularity") ?
One simple example: there are many BADIs that allow synchronous calculation or validation (e.g. checking data fields and sending a custom error/warning message). IMHO nobody would want to implement this using events and asynchronous processing on SAP BTP. So this is a typical use case for in-app key user or developer extensibility.
On the other hand, there may be applications where it makes sense to implement them on SAP BTP.
Hello again Thomas Schneider. It seems to me that people often confuse Asynchronous with slow, but this is far from the reality. It is worth making the comparison with Fiori Apps. If you create a Purchase Order using UI5, ALL communication with the Backend ERP -- including both calculations and validations -- is Asynchronous. When you hit the Save button on your Fiori App (which triggers a UI5 'Saved' Event), there is Asynchronous communication with the Backend, and once all the work has been done in the Backend, you are provided a popup in your web browser/Frontend showing you the new PO number.
If Asynchronous communication is unworkably slow, the entire technical foundation of UI5 represents a very large error made by SAP ?
PS If there is In-App extensibility (i.e. Classic BAdIs) available, of course no one should hesitate to use it: it doesn't require an additional ABAP Server (i.e. eSteampunk) running alongside a closed ABAP Server, communicating via RFC (?).
Hello Thomas Schneider - Very helpful blog. I have a question. Is it possible to adopt the same principle on SAP ECC system with Netweaver (ODATA Calls) and move some of the custom code to SAP BTP using ABAP Restful Programming but I without using RAPBO. ?
in ECC you can use side-by-side extensibility on SAP BTP with OData. But you cannot use the Restful ABAP Programming (RAP).
I would like to point you to the latest document (https://www.sap.com/documents/2022/10/52e0cd9b-497e-0010-bca6-c68f7e60039b.html) and to the communities regarding your questions on RAP:
ABAP Extensibility https://community.sap.com/topics/abap-extensibility
Embedded Steampunk and 3-Tier: SAP S/4HANA Cloud ABAP Environment | SAP Community
RAP: ABAP RESTful Application Programming Model (RAP) | SAP Community