Creating Tier 2 Cloud APIs

To set up a private edition system tiered development, the following factors are considered:​

• Initial setup​
• Understanding release state, release contracts, and usage visibility​
• Understanding developer authorizations​
• Understanding ABAP test cockpit checks

The initial setup comprises the following:​

Using the report RSMAINTAIN_SWCOMPONENTS, which is available as of ABAP Platform 2022, administrators can create and configure software components. Software components created will be classified as either "ABAP cloud" or "ABAP classic", along with transportability (either Transportable or Local).​

All objects created in a software component of the type ABAP Cloud must follow the ABAP cloud development model. By contrast, objects in software components of the type ABAP classic can be of any type. ​

Objects in ABAP cloud software components have unrestricted access to any and all objects in the same software component. However, to access objects in ABAP classic software components, those objects must be specifically released. As always, public released local SAP APIs are accessible.​

Objects in ABAP classic software components have unrestricted access to ABAP cloud-based development objects. Similar to ABAP cloud, they also have access to any and all objects in the same software component. However, they are allowed to use all SAP APIs, whether released or not.​

To facilitate the structuring of customer software projects, a structure package should be created for each software component created by the customer. ​

Development Packages​

Underneath the structure packages, one or more development packages (depending on individual project needs) can be created to hold all needed development artifacts.​

Authorizations​

There are a few authorization objects to make note of. First, for administrators setting up software components, the authorization object S_CTS_ADMI is required.​

Second, if customers desire to restrict developers to tier 1 development only, or if some developers will work in tier 1 while others will work in tiers 1, 2, and 3, then the authorization object S_ABPLNGVS can be used to design the appropriate permissions to developers. The procedure is as follows:​

• Using the transaction code SACF, activate authority checks using the authorization object S_ABPLNGVS​.

• Create two roles. One role will be assigned to developers who are restricted to tier 1 development only. The other will be assigned to developers who are allowed to develop in all three tiers, if applicable to the customer. Both roles can be created by using transaction code PFCG and by using the role SAP_BC_ABAP_DEVELOPER_5 as a template for copying. This role contains the S_ABPLNGVS authorization object​.

• Maintain the authorization field ABP_LNG_VS for each individual developer. For developers who will develop in tier 1 only, the value to be maintained is ABAP For Cloud Development. For all other developers, the value is All activities (that is, tiers 1, 2, and 3)​.

Once the necessary software components and packages have been set up, then development can begin. The wrapper object is created in tier 2. It must be created in a software component of the type Standard ABAP (ABAP Classic). It is highly recommended by SAP to build the wrapper as ABAP Cloud-compliant as possible. For this purpose, ABAP test cockpit checks which check compliance is used – the specifics of which will be discussed shortly. However, since the access of a non-released API (the reason for a wrapper in the first place) would result in an ABAP test cockpit check error, an ABAP test cockpit exemption is necessary to allow this access. Once the wrapper is finalized, it is released so that it can be used by objects in tier 1.

One important distinction to make note of is the difference between "mitigation" and "wrapping". Wrapping implies that a non-released SAP API will be made available for usage in tier 1, whereas mitigation refers to a new object (implementing missing functionality) being created instead (although still made available for tier 1 access).

Currently, the object types recommended by SAP to be wrapped are as follows:

• ABAP RESTful application programming model BO
• Function Module
• Class / Interface
• CDS View
• Table

Other types are currently not recommended. The wrapper object for the first three of the objects in the previous list is recommended to be a class / interface, and likewise a CDS view for the latter two.

For mitigation scenarios, SAP recommends the following:

• CDS Table Function
• AMDP Method

For the first option, a CDS view (which accesses the table function) would serve as the released object for tier 1 usage and for the latter option, a class (accessing the method) would suffice.

As mentioned previously, SAP strongly recommends that wrappers should be created as ABAP Cloud-compliant as possible (with the exception of usage of the non-released API). To facilitate this approach, ABAP test cockpit checks can be used to ensure compliance and to make sure exceptions to ABAP Cloud rules are documented and governed appropriately. This approach pays off, if, in the future, SAP releases the API. If public SAP APIs are provided and replace non-released objects that are used in wrappers, the ABAP test cockpit detects this and suggests refactoring options.

The primary ABAP test cockpit check variants to use to verify ABAP Cloud compliance are:

• ABAP_CLOUD_DEVELOPMENT_DEFAULT

  This variant can be used to confirm that your ABAP code is cloud ready. With this check variant, basic ABAP Cloud rules can be enforced. Moreover, with the check category API Release included in this check variant, a consistent release of the wrappers for ABAP Cloud and stability in case of changes of the wrappers can be ensured by enforcing release contract rules.

• ABAP_CLOUD_READINESS

  Objects created under tier 2 (software component based on ABAP classic) can, on an individual basis, have their language set to ABAP Cloud. For customers that intend to migrate those objects to tier 1-based software components, this variant can confirm that ABAP Cloud rules for those objects have been followed. In particular, this variant checks that only object types available in ABAP Cloud are developed, only ABAP Cloud language statements are used, and that only released SAP APIs are called.

We have mentioned frequently in the course about the importance of released APIs. As discussed earlier, software updates with cloud software happen regularly and extensions improperly designed and implemented have the potential to create disruptions for customers.

To facilitate stability, development objects intended to be used with extension development are explicitly released and also maintained with a release contract and a use visibility. All three options are maintained simultaneously on the same screen. Both released SAP development objects as well as released custom wrappers follow this process and once releasability options are maintained, they are consumable from tier 1.

The options that must be maintained are as follows:

• Release State

  This parameter indicates that the development object is "released" (that is, available for usage)

• Release Contracts
• Extend (C0)

  A development object that is enabled for extensibility has the release contract Extend (C0) assigned. Depending on the type of object in question, there may be additional prerequisites before extension points can be defined.

• Use System-Internally (C1)

  This designation is for development objects that are used for consumption. The assignment of C1 is required for any development object used in an extension implementation. As a custom wrapper by definition is to be used by consumption in the Tier 1 layer C1 is the appropriate value for this parameter.

• Usage Visibility

The following two options can be set for usage visibility:

• Use In Key User Apps is for released objects that are intended to be used by key user extensibility tools.
• Use In Cloud Development is for released objects that are intended to be used by on-stack developer extensibility.