Exploring Released APIs

As mentioned in Unit 1 Lesson 2, Introducing the Clean Core Approach, one of the most important parts of the clean core concept is the use of upgrade-stable interfaces in SAP S/4HANA Cloud. This helps contribute to software updates that, when applied, are smooth and easy without disruption.

To take advantage of this benefit, both SAP and customers work together. On the SAP side, SAP provides public-released interfaces, consisting of several types. In addition, SAP guarantees the stability of these interfaces from release to release, so that customers can use them with confidence. On the customer side, customers agree to only use the public-released interfaces in both their new developments (customer-created artifacts) and extension developments (extension implementations). In actuality, this is enforced by syntax checks and ABAP test cockpit checks in ABAP development tools for Eclipse as part of the ABAP Cloud development model, the specifics of which will be discussed in the next unit.

These released interfaces originate from several sources. The first is ABAP platform cloud available in SAP BTP, ABAP environment, and also SAP S/4HANA Cloud, ABAP environment. They are commonly referred to as local ABAP platform APIs. Since both products use the same ABAP platform cloud code line, an SAP object (such as a data element, for example) that is released is available in both places. This way, developers can put code where they feel it should belong, or even in both places, if that is the preferred approach.

Recognizing that in a cloud-native world, certain SAP objects may not be suitable, SAP has systematically replaced them with more cloud-designed equivalents.

There are several types of public-released interfaces available for usage in SAP S/4HANA Cloud and a good way to understand them is by purpose.

The first purpose is interfaces intended to be consumed by remote (non-SAP S/4HANA Cloud) sources, such as custom applications running on SAP BTP. These interfaces (commonly referred to as remote APIs) can be OData services created using the ABAP RESTful application programming model, as well as SOAP services. We have explored how OData services can be consumed by both SAP Fiori and SAP Build Apps in application development. Both of these were direct call scenarios (synchronous) initiated directly from the application. However, many applications are designed as asynchronous (an indirect call scenario). In an asynchronous scenario, rather than communicating directly, the sender and receiver use a middleware broker to exchange information as messages. Cloud Integration, a capability within SAP Integration Suite, is a service that runs on SAP BTP, and is specifically designed to be used in these types of scenarios. Both an OData and a SOAP adapter are provided so that developers can utilize OData and SOAP services respectively.

Another service offered as part of SAP BTP is the SAP Event Mesh, which allows applications to communicate with one another via asynchronous events. This type of communication allows the design of event-driven business processes. With an event-driven architecture, you have an event provider that raises an event, and an event consumer that is notified of the event and reacts accordingly. SAP Event Mesh functions as the "glue" between the provider and consumer. ABAP RESTful application programming model supports event-driven design out of the box and ABAP RESTful application programming model BOs can function as either provider or consumer, depending on the design scenario.

The second purpose is interfaces intended to be consumed locally (that is, SAP S/4HANA Cloud based). The consumption of these interfaces can take the form of a custom application built using the ABAP RESTful application programming model, or maybe a BAdI implementation. In designing these consumptions, developers can utilize classes and CDS views, among other possibilities, to facilitate access to SAP S/4HANA Cloud functionality. These local interfaces are commonly referred to as local APIs. To take a simple local API example, normally, if a developer needed access to the country table, they would select data directly from table T005. However, a local CDS view "I_country" exists (and has been released), which provides access to this data.

Finally, there are interfaces that are used for extension purposes (local extension points). Similar to local APIs, these extension points exist in SAP S/4HANA Cloud and developers create their extension implementations there. BAdIs that were first introduced with SAP R/3 4.6(c) are available in SAP S/4HANA Cloud and with the ABAP RESTful application programming model being the pre-eminent programming model used by ABAP Cloud. An extensibility model for it has also been designed and is available for developers to utilize also.

Both local and remote public APIs, as well as local extension points for SAP S/4HANA Cloud, are visible using SAP Business Accelerator Hub, and it can continue to be used for discovery purposes. However, as an additional option, ABAP development tools for Eclipse has the released objects view, which shows the developer what is specifically released for usage in ABAP Cloud development. Whereas SAP Business Accelerator Hub shows remote APIs, events, CDS views, ABAP RESTful application programming model BO interfaces, and BAdIs, the released objects view shows additional objects released for development such as data elements, authorization objects, and CDS views.

A different but closely related feature in ABAP development tools for Eclipse is its ability to detect the usage of non-released APIs and if a suitable replacement is available, to issue a syntax error message suggesting the replacement to use. As an example, table T005 (Countries) is not released. However, a replacement CDS view I_COUNTRY is available. Any access to table T005 results in a syntax error with the following message: