Exploring How to Make Extensions Clean Core Compliant

Embarking on your SAP S/4HANA Cloud journey is exciting, but it also demands a precise understanding of clean core principles. As businesses grow and evolve, they often find themselves in need of extensions to their ERP systems. Extensions offer immense value by allowing you to customize applications to meet particular needs. However, if not done in a clean core-compliant manner, these extensions can sometimes lead to complications and inefficiencies. In this lesson, we look at this second dimension of clean core, which is "clean core extensibility". As we saw in the previous lesson each dimension has a goal or a mantra. For this dimension, the goal is to "Keep the extensions clean". Following the principles of clean core extensibility helps to maintain system integrity, improve efficiency, and facilitate smooth upgrades.

Watch the video to get an overview of the dimension — extensibility.

Mantra: "Keep the extensions clean".

Note

Clean core extensibility is covered in detail in the Practicing Clean Core Extensibility For SAP S/4HANA Cloud learning journey. This lesson provides a high-level summary of clean core extensibility principles. For more information, refer to the learning journey.

The first aspect of clean core compliance is to avoid creating extensions whenever possible. Before creating an extension, it's important to thoroughly evaluate whether the desired functionality can be achieved through standard ERP features or configuration. This evaluation is normally determined while implementing the first dimension (business processes). Once the business processes are clean core-compliant, it is easy to determine if SAP S/4HANA Cloud out-of-the-box functionality implements those processes. If not then custom development and/or extension development is necessary. By minimizing the use of extensions, you can reduce the complexity and maintenance overhead of your ERP system.

Further to this requirement, to approve extensions, companies must set up a clean governance structure with high demands. The documentation of why the extension was needed must be clear, and so must the proposed value of the extension.

When creating extensions, it's crucial to ensure that they do not break an upgrade. An extension that is not clean core compliant can cause issues ranging from data corruption to complete system failure. This risk means that the extensions must be designed to enable smooth transitions during ERP upgrades. By following clean core principles, you can build extensions that adapt to new versions of the ERP system, minimizing disruptions and downtime.

To ensure that extensions don't break an upgrade (or that an upgrade doesn't break an extension), the extension must be clearly separate from SAP S/4HANA Cloud code. The SAP S/4HANA Cloud extensibility model was created in part to fulfill this purpose. The model, when followed ensures that extensions do not cause issues as customers receive continuous innovation from SAP. It is anchored around the following principles:

• Extensions can only be implemented internally within SAP S/4HANA Cloud as on-stack extensions or externally as side-by-side extensions running on SAP Business Technology Platform.
• Extensions can only use released local or remote public SAP Application Programing Interfaces (APIs) and BAdIs and ABAP RESTful Application Programming Model Business Object (BO) extension points.
• Extensions can only be implemented using cloud-enabled and released technologies.

Now, we look at the first two, followed by the third. Regarding the first principle, there are three extension types divided into two categories:

• On-stack extensions, created within SAP S/4HANA Cloud. These extensions can be key user extensions (type 1) or developer extensions (type 2).
• Side-by-side extensions, created within SAP Business Technology Platform (type 3).

Generally, type 1 or type 2 extensions are created when close coupling to SAP S/4HANA Cloud is necessary. Type 3 extensions are created when a looser coupling is acceptable.

Closely related to the first principle, clean core extensibility requires the use of "released" APIs and extension points (BAdIs or BO extension points). Non released objects cannot be used.

Both principles, when taken together, provide complete transparency (a clear separation) regarding customer code versus SAP code.

We now turn to the third principle of the SAP S/4HANA Cloud development model: cloud enabled and released technologies. The two primary guideposts for customers to follow to implement this principle are:

• ABAP Cloud Development Model
• Three Tier Extensibility Model

SAP created the ABAP Cloud development model (ABAP Cloud) to meet the demands of cloud native development. It represents an evolution of classical ABAP, retaining the familiar features and advantages of the ABAP language, while simultaneously removing concepts that are incompatible with SAP S/4HANA Cloud. Briefly summarized, ABAP Cloud is based on the following:

• Only approved ABAP Cloud object types (ABAP RESTful application programming model artifacts, for example) can be developed.
• ABAP Cloud language is enforced via syntax check.
• Usage of released APIs is enforced via a syntax check.
• ABAP development tools for Eclipse are used to create all development objects.

We mentioned in a previous lesson that there are three variations of SAP S/4HANA that customers could potentially adopt:

• SAP S/4HANA Cloud Public Edition
• SAP S/4HANA Cloud Private Edition
• SAP S/4HANA (for customers who desire an on premise / hosted approach)

Each customer's journey to the cloud is different. Some customers use public edition, while others prefer to use the private edition. Some customers adopt an on premise solution first but eventually move to public edition. Recognizing this difference among customers SAP has designed the three-tier extensibility model to accommodate different customer needs at different stages of their cloud journey. The model is named as it is due to three tiers (options) being available. We discuss the first two tiers now, and the third option in a moment.

Tier 1 is mandatory for public edition customers and recommended for private edition customers. It is also recommended for on premise customers, especially if they plan to move to public or private edition in future, as artifacts developed in accordance with Tier 1 principles will smoothly migrate with minimal disruption. It means that extensions are exclusively developed using ABAP Cloud and the SAP S/4HANA Cloud extensibility model. Classic ABAP and classical extensions are not supported.

Tier 2 was created for customers adopting private edition / on premise. For those customers, there may be an object (a function module for example ) that has not yet been "released" by SAP but is still necessary for successful extension development. The unreleased object is "wrapped" by a released object (for example, a released ABAP class in one of its methods, calls an unreleased ABAP function module). Since the wrapping object is released, the rules of ABAP Cloud are satisfied (only released APIs can be used). Customers can use the Customer Influence Tool to ask SAP to release APIs. When the API is released by SAP, the wrapper can be removed.

Build cloud-compliant extensions, which are integrated via stable interfaces.

This principle is related to the first one. In the first principle, we say that extensions must be avoided unless necessary. However, here we say that if extensions are needed, project teams must carefully consider how the extension is to be implemented and consider future needs.

This involves two things. The first is that careful consideration must be given whether to create the extension as an on stack or side-by-side extension following the SAP S/4HANA Cloud extensibility model. The second, which is applicable to private edition and on premise customers is whether to create an extension using classical extension techniques. Classical extensions for the third "tier" of the three-tier extensibility model. Extensions created this way are discouraged due to the high likelihood of disruption, both when the system is upgraded and the certainty of disruption if customers move to public edition. Nevertheless, if Tier 1 or Tier 2 approaches are not feasible, then classical extensions (with the customer understanding the implications) is acceptable. Classical extensions comprise Tier 3 of the three-tier extensibility model.

To help with this decision, customers can use the SAP Application Extension Methodology. This methodology allows customers to assess their extension use cases and define an extension target solution in a structured and formalized way.

In conclusion, adhering to clean core compliance principles is essential for creating sustainable and efficient ERP extensions. You can maximize the effectiveness of your ERP system while minimizing complexity and maintenance overhead by:

• minimizing the use of extensions.
• ensuring that extensions do not break upgrades.
• making extensions cloud-compliant.
• understanding customer requirements.

By following the guidelines outlined in this course, businesses can make informed decisions when evaluating and applying clean core principles to their ERP extensions. This approach results in a more streamlined and future-proof ERP system that meets the evolving needs of the organization.

Extensions must never duplicate SAP S/4HANA Cloud standard functionality.