By Karl Kessler, VP of Product Management, SAP AG  Over the last decades, SAP has always looked for new ways to empower modern enterprises to run their core business processes very efficiently while adapting their standard processes to their market needs in a very flexible fashion. Traditional SAP Business Suite customers have thoroughly used all available technologies to extend SAP’s standard offering. Wherever possible, the customers have used predefined extension points in the SAP software. They even modified the SAP applications to their own needs if stable extension points were missing. However, this freedom of choice comes at a significant price whenever life cycle management tasks such as SAP upgrades or support package implementations have to be carried out. Custom extensions need to be merged into the newly delivered SAP version. SAP has developed very specialized tools to help with this process such as the Modification Assistant, and the transaction SPAU (process after upgrade), but the overall process is time-consuming, error prone, and costly.

Clean Core Philosophy

As a consequence, SAP recommends to its customers to follow a clean core strategy after their transition to SAP S/4HANA, which means to keep the SAP S/4HANA core as clean as possible and implement all extensions to the core on the SAP Business Technology Platform (BTP) in their preferred programming language (Java, node.js, or ABAP) using well-defined SAP S/4HANA APIs that are properly documented in SAP API Business Hub. There is nothing wrong with this approach, and as a matter of fact, many partner solutions and decoupled extensions work this way. While SAP BTP is the perfect start to build innovative cloud applications optimized for SAP HANA, it requires remote access to SAP S/4HANA resources. Depending on the nature of the extension, this can lead to complex side-by-side deployments, especially if the extension is tightly coupled with the SAP S/4HANA core with frequent access to SAP S/4HANA resources.

Key User Extensibility

Extensions that add simple fields to the user interface and custom logic, such as a Business Add-In (BADI) to a standard business process cannot be implemented using a side-by-side pattern. Therefore, SAP has provided the so-called key user extensibility tools (often referred to as in-app extensibility), which allow extension of SAP S/4HANA applications using a SAP Fiori-based tooling environment. Key users can extend a running SAP Fiori application entering a corresponding author mode (“Adapt UI”) directly from the SAP Fiori launchpad. They can change the layout of the screen and add new fields on the fly, which are saved and retrieved as part of the application without writing a single line of code. While these tools do not require coding skills, they are limited since they cannot fully access the underlying context of an application like a programmatic extension would allow.

Building Extensions on Top of Released APIs and Objects

The natural next step is to find a way to extend an application directly on the SAP S/4HANA stack without disrupting the life cycle. This can only be achieved based on a software layer that exposes publicly released APIs (such as ABAP classes) and publicly released objects (such as domains, data elements, and core data services) that remain stable during software version changes. Improper use of SAP objects by custom extensions is not allowed and will be rejected by the ABAP compile-time and runtime environment. Modifications are completely forbidden. The benefit for the extensions should be paramount: No adaptations are required after a version change since all used SAP objects and APIs remain compatible. Custom and partner code continues to run without any changes.

Need for a Developer Extensibility Option for SAP S/4HANA Cloud

It’s important to look in more detail at the existing extensibility options for SAP S/4HANA Cloud and how a new developer extensibility fits into the picture. Figure 1 shows an SAP S/4HANA Cloud system. Technically, the SAP S/4HANA Cloud applications such as Finance, Procure, Produce, and Sales are implemented based on the ABAP platform cloud stack. Inside this stack the ABAP VM executes the applications and accesses the underlying SAP HANA database. The only way to extend the SAP S/4HANA Cloud applications is by means of key user extensibility tools. A power user can access these SAP Fiori-based tools in the SAP Fiori launchpad. He or she can create new custom fields, custom business objects, change the layout, etc. Extensions are created in a separate SAP S/4HANA Cloud system instance and then transported to the productive system instance without manual interaction by the power user. Figure 1 Figure 2 shows how to extend SAP S/4HANA Cloud using a side-by-side extensibility approach powered by SAP BTP. In the diagram, SAP BTP, ABAP environment (project nickname “Steampunk”) is shown, but the approach also works similarly with Java or node.js. Like SAP S/4HANA Cloud, SAP BTP, ABAP environment is based on SAP HANA. Customers and partners can develop and run their extensions using public interfaces of the underlying ABAP platform cloud stack. Figure 2 Applications are written using the ABAP RESTful application programming model, which builds on top of core data services adding transactional capabilities, service exposure and binding for consuming SAP Fiori applications. Customers and partners use the ABAP Development Tools to connect to an SAP BTP ABAP environment system instance and create their ABAP development artefacts. Whenever such an extension application needs to access the SAP S/4HANA Cloud system, it must call a public remote API from SAP API Business Hub. Both SAP S/4HANA Cloud and SAP BTP, ABAP environment are based on the same ABAP platform cloud innovation codeline. All innovations that have been created for SAP BTP ABAP environment are technically present as part of the SAP S/4HANA Cloud technology stack in principle (they were basically hidden so far). Figure 3 shows the new SAP S/4HANA Cloud ABAP environment. Developers use the ABAP Development Tools for Eclipse to directly connect to the SAP S/4HANA Cloud system. Customers and partners can develop their extensions directly on the SAP S/4HANA Cloud technology stack using the RAP programming model and the cloud-optimized subset of the ABAP language. Like with SAP BTP, ABAP environment, customers and partners can use the public interfaces of the underlying ABAP platform cloud stack. In addition, they can use the public interfaces and released objects of SAP S/4HANA Cloud locally. Figure 3

Comparison of Extensibility Options

The extensibility options for SAP S/4HANA Cloud are highlighted in Figure 4. The on-stack extensibility options (key user extensibility and developer extensibility) are shown in the two joint columns on the left. The side-by-side extensibility options powered by SAP BTP are shown in the column on the right. As we have seen, the key user extensibility offers low code/no-code tooling access, creating custom fields and maintaining the layout. Figure 4   Developer extensibility is well-suited for tightly coupled extensions. Customers and partners can directly access the released SAP S/4HANA Cloud business objects without the need for remote access or data replication. Side-by-side extensions on SAP BTP can be written in ABAP, Java, or node.js. Access to SAP S/4HANA Cloud objects requires remote access using a public API test tool for SAP S/4HANA Cloud from SAP API Business Hub.

The Road Ahead

Now that the concept of SAP S/4HANA Cloud is laid out, the question arises what happens to SAP S/4HANA on-premise. Of course, the traditional way to build ABAP-based extensions in that on-premise environment remains. Customers are not forced into a new extensibility model. However, the advantage to build an extension on stable public interfaces should be obvious. To gather experiences with the new model, SAP works together with customers and partners in an early adopter project in the second half of 2021. The feedback will be incorporated into the ABAP platform cloud technology stack. SAP will offer the developer an extensibility option based on stable interfaces also for SAP S/4HANA on-premise systems and likewise for SAP S/4HANA Cloud, private edition as part of the RISE with SAP initiative. Customers and partners can then choose to use this option also in on-premise, resulting in a single codebase approach for cloud and on-premise over time.

Summary

In this article, we introduced the SAP S/4HANA Cloud ABAP environment, which provides ABAP developers with full ABAP development tool access to released SAP S/4HANA Cloud business objects and extension points. These interfaces are guaranteed to be stable, removing adaptation efforts after a version change. ABAP developers can directly connect and carry out on-stack development tasks similarly as in the on-premise world. After successful introduction in SAP S/4HANA Cloud, this approach will also be introduced as an extension option in SAP S/4HANA on-premise so that customer and partner code can be designed in a deployment-neutral fashion (both cloud and on-premise). With the theory fully captured, click here for concrete extension examples using the tools described in the article.

What Does This Mean for SAPinsiders

1. Enhance developer extensibility. With SAP S/4HANA Cloud ABAP environment, SAP adds developer extensibility to SAP S/4HANA Cloud.
2. Connect tools to SAP S/4HANA. Customers and partners can directly connect to SAP S/4HANA Cloud with their ABAP Development Tools for Eclipse.
3. Access to business objects through APIs. Developers can access the business objects of SAP S/4HANA Cloud by means of local released APIs.
4. Enable a new programming model. SAP enables the ABAP RESTful application programming model for SAP S/4HANA Cloud.