ABAP Cloud – How to mitigate missing released SAP APIs in SAP S/4HANA Cloud, private edition and SAP S/4HANA – The new ABAP Cloud API enablement guide

Last year SAP announced the availability of the new ABAP Cloud development model in SAP S/4HANA Cloud, private edition and SAP S/4HANA. More information about that can be found in Boris Gebhardt’s blog post (“How to use Embedded Steampunk…”). Part of the announcement is the new ABAP extensibility guide. In this guide the 3-tier model was introduced to establish ABAP Cloud in SAP S/4HANA Cloud, private edition and SAP S/4HANA while retaining full flexibility in these environments.  

In this blog post I will introduce a guide dedicated to tier 2 – Cloud API Enablement. 

3-Tier Extensibility Model for SAP S/4HANA Cloud, private edition and SAP S/4HANA 

The 3-tier model is the way modern ABAP Cloud development is brought to SAP S/4HANA Cloud, private edition and SAP S/4HANA. It allows you to separate between:  

• Extensions that follow the cloud extensibility model (tier 1);  
• The tier 2 as Cloud API Enablement layer 
• Existing custom code or legacy developments using classic extensibility techniques (tier 3).  

Tier 2 

One of the main aspects of the ABAP Cloud development model is, that only released public SAP APIs can be used. But what to do if such a public API is missing? 

With tier 2 you can mitigate this by building custom wrappers around the required non-released SAP objects and releasing them for Cloud Development. Hence, using the wrappers as a custom interface to SAP objects provides a mechanism for enabling non-released SAP objects for ABAP Cloud and tier 1. 

In the following picture we summarize how the 3 tiers shall work together and interact with SAP development objects: 

Let’s walk through it together: 

• Starting on the upper left, in tier 1, syntax and runtime checks ensure that you follow strictly the ABAP Cloud rules and that you only access released development objects. 
• These released development objects are the public SAP interfaces and in addition the wrappers around non-released SAP objects in tier 2. 
• Tier 2 is the Custom SAP Interface, that can be used to mitigate the effect of missing public SAP APIs. In this tier, the ABAP Cloud rules are enforced by ATC. Thereby, the access to non-released SAP objects required for building wrappers can be controlled.
• Tier 3 contains the classic ABAP development. New developments in tier 3 shall also follow ABAP Cloud rules as much as possible. This is enforced by ATC as well.
• Existing objects in tier 3 were developed without enforcing ABAP Cloud rules 

More details about how to use ATC in the three tier model is provided in How the ABAP Test Cockpit supports you to adopt ABAP Cloud.

The Custom SAP Interface (tier 2) is the stirrup to enable ABAP Cloud development in SAP S/4HANA Cloud, private edition and SAP S/4HANA while leveraging the broad scope and the flexibility of these products. Now you might ask: 

• How shall tier 2 be set up in my development system? 
• What are guidelines and best practices for creating wrappers? 
• How can they be used in tier 1? 

We are happy to provide answers to these questions in the newly published ABAP Cloud API Enablement Guidelines for SAP S/4HANA Cloud, private edition, and SAP S/4HANA