Exploring Clean Core Extensibility Best Practices

Objective

After completing this lesson, you will be able to explore clean core extensibility best practices.

1st Generation: 3-Tier Extensibility Model (Now Sunset)

The original 3-tier extensibility model (now sunset) provides a framework for customers to decide how to implement extensions. Tier 1 (ABAP Cloud based) and Tier 2 (cloud API enablement) are recommended. Use Tier 3 (classical) only when absolutely necessary.

While the original 3-tier extensibility model is now sunset in favor of the new level based clean core concept this section will briefly review it as understanding it is useful in grasping the evolution to the new level based approach. Moreover customer code that was designed and implemented under the original 3-tier guidance (particularly tier 2 wrappers) does not necessarily need to be migrated to the new level based approach.

The original tier based approach to customer extension development was centered around the following 3 tiers:

  • Tier 1 (ABAP Cloud): The preferred, future-proof, and upgrade-safe way. For all new development. Uses a restricted, cloud-optimized ABAP version and can only access released SAP APIs.
  • Tier 2 (Cloud API Enablement): The "bridge." For wrapping existing custom code (from Tier 3) or standard SAP objects that are not yet released for Tier 1. Its purpose is to create a stable, reusable API for Tier 1 to consume.
  • Tier 3 (Classical ABAP): The "legacy" or traditional way. For existing code and deep, complex extensions that are not possible in Tier 1. This code was tightly coupled to the system, could be problematic in the case of an upgrade and was thus recommended to be used as a last resort.

While this approach created a framework that could be used by customers in a practical way nevertheless it has been retired in favor of an evolved and even more flexible approach.

2nd Generation: Clean Core Level Concept

The Evolution: From A Flexible Approach to an Even More Flexible Approach

The Evolution: From A Flexible Approach to an Even More Flexible Approach

Initially, the "Clean Core" message was often perceived as a binary, all-or-nothing principle: "You are either clean or you are not." This approach while effective nevertheless produced some challenges for customers particularly in regards to the fact that some APIs while not officially "released" were quite stable and were unlikely to cause problems in upgrade scenarios Moreover as a practical matter it is unrealistic to expect customers to simply throw away all of their existing custom code.

Recognizing this, SAP has evolved the 3-tier model to encompass a more pragmatic based approach based on levels allowing customers the flexibility to engage in more of a risk based approach in managing their custom code. This approach acknowledges that not all extensions are created equal and provides a clear, structured framework for developers and architects. It transforms clean core extensibility from a rigid rule into more of an actionable roadmap.

Clean Core Extensibility Model Overview

The clean core extensibility model aims to improve transparency and reduce technical debt in SAP S/4HANA extensions. It does this in the following ways:

  • A more flexible clean core level concept with four levels (A to D), where Level A is the highest quality.
  • Customers are encouraged to extend SAP S/4HANA Cloud Private Edition with the highest level possible.
  • Higher clean core levels reduce technical debt, simplify upgrades, and align with SAP best practices.
  • Extensions are evaluated based on the lowest-ranked technology used within them.

How Does The Clean Core Level Concept Enhance Extensibility Options For Customers?

The transition from the 3-tier extensibility model to the clean core level concept enhances the evaluation of extensibility in three main ways:

  • Pragmatic Classifications: The new level-based approach provides a nuanced distinction between upgrade-stable and risky extensions.
  • ABAP Classic: Classic ABAP objects are no longer uniformly categorized as high-risk, allowing for a more flexible assessment.
  • The Best of Both Worlds: The clean core level concept acknowledges the value of both legacy code and modern extensions while promoting decoupling

So How Do The Levels Work?

The clean core levels categorize extensions based on their compliance with SAP's standards for upgrade stability.

  • Level A extensions use released APIs and are fully supported by SAP, ensuring maximum upgrade stability.
  • Level B extensions leverage classic APIs and technologies, providing a broader scope for enhancements.
  • Level C extensions access internal objects, posing (manageable) risks and allowing for specific customer needs.
  • Level D extensions use not recommended objects, representing the highest risk and technical debt.

Let's explore these concepts.

A New Classification System

The previous paragraph highlighted the complete set of terms used to classify ABAP objects:

  • Released APIs: Stable, supported, and safe for customers and partners to use for building extensions They are upgrade-safe by design.
  • Classic APIs: Classic ABAP artifacts that while not built on the latest frameworks, are recognized as upgrade safe and classified as such.
  • Internal Objects: Artifacts that are not classified as "Classic APIs". A changelog based approach enables organizations to assess the upgrade risk of "Internal Objects" in advance, supporting informed decision-making before major upgrade projects.
  • Not Recommended Objects: Artifacts known to introduce upgrade challenges, helping customers avoid risky extensions early in their projects

Level A: Clean Extensions based on Released APIs

Level A: Clean Extensions based on Released APIs

  • Level A Overview:

    • Highest standard in SAP extensibility.
    • Ensures future-ready solutions with maximum upgrade stability.
    • Uses released APIs, extension points, modern technologies, frameworks, and development patterns.
    • Aligns with SAP's clean core vision.

  • Coverage:

    • Includes only extensions built on released SAP APIs and extension points.
    • Applies to both side-by-side implementations on SAP BTP (SAP Build for CAP and ABAP Cloud) and on-stack development within SAP S/4HANA systems.
    • On-stack extensions must use key user or developer extensibility tools with relevant ABAP language versions.
    • Does not cover the complete scope of SAP S/4HANA Cloud Private Edition.

  • SAP Involvement:

    • Extensions rely on officially released SAP objects governed by stability contracts.
    • Interfaces and extension points can be found in the SAP Business Accelerator Hub, the Cloudification Repository, and directly in the system.

  • SAP S/4HANA Cloud public edition

    • Level A aligns with the development approach for SAP S/4HANA Cloud public edition.
    • On-stack extensions created for SAP S/4HANA private edition generally require adaptations to be portable to the public cloud.
    • Side-by-side extensions on SAP BTP are more likely to be compatible with the public cloud, as they decouple business logic from the core system.
    • Complete parity is not guaranteed due to differences in API availability and application scope between SAP S/4HANA versions.

Level B: Use of Classic APIs

Level B: Use of Classic APIs

  • Level B Overview:

    • Addresses requirements not met by released APIs alone.
    • Utilizes "classic APIs" that are well-established, broadly recommended, and thoroughly documented.
    • Offers a broader scope for process enhancements and customizations compared to Level A.
    • Follows SAP’s best practices for upgrade stability.
    • Extensions benefit from SAP’s internal quality assurance and represent low-risk options.

  • Eligibility:

    • Extensions qualify for Level B when they use only SAP objects and development patterns classified as classic APIs or released APIs.
    • This includes:
      • Wrappers around classic APIs to facilitate use in Level A applications (e.g., using BAPI_PO_CREATE1).
      • Classic ABAP extensions, such as ABAP List Viewer implementations within Dynpro or Web Dynpro environments using classic APIs like CL_GUI_ALV_GRID.
      • Custom objects developed using the ABAP language version "Standard," without referencing restricted or unsupported SAP objects.
    • Level B extensions maintain a high degree of upgrade stability by adhering to proven development practices.

  • SAP Involvement:

    • Encompasses objects and extension points explicitly nominated by SAP experts as classic APIs, despite lacking formal stability contracts.
    • Includes a wide range of legacy APIs, user exits, BAdIs, and established frameworks like SAP GUI and the ABAP List Viewer grid, which are exposed for customer use in SAP S/4HANA on-premise and SAP ERP.
    • Where released APIs are unavailable, classic APIs and extension points offer the next-best extensibility option.
    • A key resource for identifying classic APIs and extension technologies is the Cloudification Repository (explained in the next lesson).

Level C: Use of Internal Objects

Level C: Use of Internal Objects

  • Level C Overview:

    • Involves the use of SAP internal objects not intended for customer use.
    • These objects are not officially released, recommended, or cloud-ready, and fall outside SAP’s formal support scope.
    • Documentation may be incomplete or absent, with no long-term stability or usage guarantees.
    • Offers advanced technical capabilities but poses risks to future upgrade stability.
    • The new changelog for SAP objects allows customers to analyze and plan for potential upgrade impacts.

  • Eligibility:

    • Extensions fall into Level C when using objects or development patterns that are neither formally released (Level A) nor nominated as mature (Level B).
    • Examples include direct use of internal function modules, classes, or read-only access to SAP tables not endorsed for external consumption.
    • These extensions fulfill specific customer requirements not covered by higher-level APIs but have a risk of future incompatibility.

  • SAP Involvement:

    • Covers SAP objects not designated as released or classic APIs, and not explicitly classified as not recommended.
    • Internal objects are subject to change without notice or compatibility guarantees.
    • SAP may reclassify internal objects as "Classic APIs" or "Not Recommended", shifting the level (to B or D, respectively).
    • These changes are driven by customer feedback, evolving product strategies, or observed upgrade challenges.

  • Changelog for SAP Objects:

    • Introduced to enhance transparency and support customers in managing Level C risks.
    • Features include:
      • Automated ABAP test cockpit checks to analyze custom code and detect incompatible changes.
      • Early access to information about future incompatible changes.
      • Increased planning reliability and transparency for timely resource allocation.
    • Encourages developers to refactor extensions toward released or classic APIs where possible.
    • Adopting the changelog helps minimize upgrade risks, achieve proactive change management, and ensure smoother transitions between SAP software versions.

Level D: Not Clean Core

Level D: Not Clean Core

  • Level D Overview:

    • Represents the highest risk category within the clean core level concept.
    • Associated with significant technical debt, maintenance efforts, and risks to system stability, data integrity, and business agility.
    • Compromises innovation due to compatibility challenges.
    • Immediate remediation is strongly recommended to align with SAP’s support guidelines and ensure long-term operational reliability.

  • Eligibility:

    • Extensions fall into Level D when using SAP objects or development patterns explicitly marked as not recommended.
    • Examples include:
      • Modifications, extensions, and unsupported write operations on SAP tables.
      • Implicit enhancements.
      • Utilization of objects designated as out-of-scope for customer consumption.

  • SAP Involvement:

    • Encompasses all objects and patterns officially declared as not recommended for external use.
    • Includes objects labeled with the "noAPI" designation, identifiable in the Cloudification Repository by filtering for the "state" set to "noAPI." This will be demonstrated in the exercise below.
    • Covers modifications, certain object usage patterns (such as direct write access to SAP core tables), and discouraged development techniques like implicit enhancements.
    • Provides transparency via a comprehensive list of discouraged objects and patterns to help customers identify and eliminate these high-risk elements from their SAP landscapes.

Utiize Object Search Features Of The Cloudification Repository Viewer

ExerciseStart Exercise

Learning

SAP FacebookSAP YoutubeSAP LinkedIn