Three-Tier Extensibility Model in SAP Cloud Systems

SAP has designed a comprehensive framework for extending its solutions, ensuring businesses can adapt their SAP systems while maintaining system stability and upgradeability. For SAP S/4HANA Cloud Private Edition, the Three-Tier Extensibility Model provides clear guidelines on how custom development can be handled in a structured and secure manner. This post will break down each tier and provide practical examples to help businesses navigate these extensibility options.

Tier 1: Cloud Extensibility Model (ABAP Cloud)

This tier is built around the ABAP Cloud development model, ensuring all custom developments adhere to cloud-first principles. The key features include:

• ABAP Cloud Enforced Syntax: Only approved ABAP object types can be developed, such as ABAP RESTful Application Programming Model artifacts.
• Strict API Usage: Only released SAP APIs can be used, enforced through syntax checks.
• Development Tools: ABAP development is done using Eclipse-based tools (ABAP Development Tools).
• Key User and Developer Extensions: Both key user extensions (such as adding custom fields) and full-stack developer extensions are supported.

For SAP S/4HANA Cloud Public Edition customers, Tier 1 is the only available extensibility option. SAP S/4HANA Cloud Private Edition customers are encouraged to use this tier as a first approach, benefiting from side-by-side extensions through SAP BTP.

Tier 1 Use Cases:

• Adding custom fields to a database table or CDS view.
• Implementing a released SAP BAdI (Business Add-In).
• Creating a custom SAP Fiori app using the ABAP RESTful Application Programming Model.

Tier 2: Cloud API Enablement

Tier 2 is unique to SAP S/4HANA Cloud Private Edition and supports use cases where customers need access to non-released SAP APIs, such as BAPIs or Classes. To ensure compliance with the cloud model, a custom wrapper is created around these non-released APIs, effectively allowing their use within the ABAP Cloud framework.

• Custom Wrappers: Developers can wrap non-released APIs, enabling their use while ensuring upgradeability.
• Compliance Monitoring: ABAP Test Cockpit checks are used to enforce ABAP Cloud compliance, allowing for exceptions (such as the use of custom wrappers).
• API Governance: After each SAP upgrade, developments using non-released APIs should be reassessed. If the API has been released, the custom wrapper should be retired and replaced with the direct API usage.

Tier 2 Use Cases:

• Creating a wrapper class for a non-released BAPI.
• Developing a CDS view that wraps around a non-released SAP table or view.
• Implementing ABAP RESTful programming around non-released SAP objects.

Tier 3: Classic ABAP Extensions

Tier 3 is reserved for classic ABAP custom development that cannot be implemented using Tiers 1 or 2. This tier presents the highest risk of software upgrade disruptions and should be used sparingly.

• No Restrictions: Unlike Tiers 1 and 2, there are no restrictions on the ABAP language or object types. Classical extension techniques can be used freely.
• Upgrade Disruption Risk: Tier 3 developments are more likely to cause issues during upgrades, so SAP advises businesses to avoid this tier where possible. Modifications should be kept minimal.

Recommended Approaches:

• Use customer includes or extension includes for DDIC extensions.
• CDS extends or CDS metadata extensions should be used for CDS extensions.
• Avoid modifications; if absolutely necessary, use the Modification Assistant.

Tier 3 Use Cases (To Be Avoided If Possible):

• Implementing a non-released BAdI.
• Extending SAP Fiori apps based on older programming models (e.g., ABAP Programming Model for SAP Fiori).
• Modifying any SAP object—use Modification Assistant when required.

Key Takeaways

1. Tier 1 is the preferred option for all SAP S/4HANA Cloud Public Edition customers and should be the first approach for SAP S/4HANA Cloud Private Edition customers. It ensures cloud-ready, upgrade-safe development.
2. Tier 2 is for cases where non-released SAP APIs are required. Custom wrappers allow usage while keeping developments cloud-compliant.
3. Tier 3 is the last resort and should be avoided where possible due to the higher risk of disruption during software upgrades.

Businesses should periodically reassess their developments, especially after upgrades, to refactor or retire customizations when they are no longer needed or when better solutions become available.

By understanding and utilizing this Three-Tier Extensibility Model, organizations can build tailored solutions that meet their specific business needs while ensuring long-term system stability and scalability.

SAP ABAP Consulting