ABAP Cloud FAQ

Customers should use RAP, ABAP CDS, the ADT tools where applicable. They should develop in classic ABAP on an as-needed basis and use ATC to check the code for ABAP Cloud. The released ABAP Platform APIs should be used to a great extent (disclaimer: some APIs only work in limited scope due to differences between the cloud and on-premise platform versions in the lower releases). Use available (but not yet released) SAP S/4HANA APIs (e.g. I_PRODUCT). See also the blog How to check your custom code for ABAP Cloud using the Cloudification Repository on GitHub, which provides the list of released APIs. For missing released APIs custom wrappers should be created. For details on the proper package hierarchy and structure for organization of your developments in the corresponding extensibility tiers please see the Extensibility Guide.

No, non-public SAP CDS views need to be wrapped and released for ABAP Cloud development by the customer.

Yes, more details are documented in the Extensibility Guide.

No, it is possible to create only objects of object types that are allowed for ABAP Cloud. If this does not work properly in your SAP S/4HANA 2022 system, please implement the SAP Note 3300493 - Enforce Language Version 5 in ABAP Cloud.

Calculation views cannot be used to enforce the clean core rules. CDS and AMDP (ABAP managed database procedures) provide a good scope and shall be used instead.

Currently, read access is supported only. Write access is planned as well but requires proper enablement on the SAP HANA layer.

The basic concepts of RAP extensibility can be found in the Extensibility Guide. Further information is available in the RAP Extensibility online documentation on SAP Help Portal.

Custom tables can be defined with the ADT in Eclipse tools, see the Create Database Tables online documentation on SAP Help Portal.

It depends on the use case. Simple field extensibility use cases should be handled with the key user tools. More complex extension scenarios should be implemented with the ADT tools. "When to use what" is explained in the Extensibility Guide.

Like modifications implicit enhancement spots should be avoided as an extension technology. Details are in the Extensibility Guide (p.30).

RAP is the default programming model in SAP S/4HANA to build Fiori apps, services and local APIs. For the public cloud scope SAP S/4HANA plans to expose RAP facades for the main SAP object types (business objects).

The answer differs for SAP S/4HANA Cloud, private and public editions. The target architecture of a modernized SAP S/4HANA Cloud, public edition core is 100% based on the SAP Fiori / SAP UI5 architecture stack. Currently, both editions contain classic and SAP Fiori based apps.

Yes, the ABAP test cockpit helps to identify such issues. See the Extensibility Guide (p.26) and the blog How to make your custom code cloud-ready and upgrade-stable for more details.

In SAP S/4HANA on-premise and SAP S/4HANA Cloud, private edition mitigations for missing APIs/extension points and existing legacy code are needed: Please see the 3-tier extensibility model described in the Extensibility Guide.

See the Extensibility Guide. There are tools for custom code remediation and ABAP test cockpit to analyze the code and to provide solution proposals (replace MARA access by I_PRODUCT access), but the clean core transformation is manual, especially for bigger changes like transforming from Dynpro to SAP Fiori.

Tightly coupled extensions run very well on Embedded Steampunk. However, when you want to decouple an extension that has its own lifecycle and user group independent of the SAP S/4HANA Cloud system or if you want to leverage the multi-tenancy capabilities a side-by-side approach is beneficial.

SAP BTP is optimized to build and run business apps and to integrate with SAP solutions (for example, the extended SAP S/4HANA system).

SAP plans to support SAP BTP ABAP Environment for Microsoft Azure in the first data center by end of Q1 2023.

Key user tools are intended for low-code/no-code extensions. More complex use cases of developer extensibility are better handled with ADT in Eclipse.

Embedded Steampunk is a new extensibility option for ABAP developers available for SAP S/4HANA Cloud, public edition (version 2208) and SAP S/4HANA 2022 (both Cloud, private edition and on-premise) often referred to as developer extensibility (in contrast to key user extensibility). Embedded Steampunk allows to develop ABAP-based extensions which are cloud-ready and upgrade-stable avoiding adaptation efforts after an SAP upgrade or version change. Embedded Steampunk enables the development of tightly coupled extensions directly on the SAP S/4HANA Cloud system. SAP offers a public interface consisting of released objects and local public APIs that extensions can use to access services offered by the underlying ABAP platform and the SAP S/4HANA business objects. Extensions are implemented with the help of the ABAP RESTful Application Programming Model (RAP).

Embedded Steampunk is not an instance of SAP BTP ABAP Environment (Steampunk) embedded into an SAP S/4HANA Cloud subscription. Embedded Steampunk is an extensibility option offered by SAP S/4HANA Cloud that inherits all capabilities of Steampunk such as RAP, the development against upgrade-stable public APIs and released objects and extension points. A developer logs on directly to the SAP S/4HANA Cloud system and develops ABAP extensions directly on top of the SAP S/4HANA technology stack. Both Steampunk and Embedded Steampunk are based on the ABAP Cloud development model.

No, the technology and content (SAP S/4HANA APIs and so on) are only available for release >= 2022.

Extension apps and extensions to SAP objects in Embedded Steampunk run on the same SAP S/4HANA Cloud technology stack. Therefore, they can have a performance impact like in private cloud or on-premise deployments and need to be implemented carefully.

Extensions implemented in Embedded Steampunk run on top of the SAP S/4HANA Cloud technology stack. All requests against local public APIs and released CDS views are executed directly on the SAP S/4HANA Cloud application server. Roles in the underlying SAP S/4HANA Cloud system can be reused. This approach is optimal for tightly coupled extensions.

Yes. See details in the blog How to use Embedded Steampunk in SAP S/4HANA Cloud, private edition and in on-premise.

As of SAP S/4HANA 2022 on-premise customers can configure "Embedded Steampunk” in their SAP S/4HANA system as described in the Set Up Developer Extensibility online documentation on SAP Help Portal.

No, tightly coupled extensions shall be implemented with Embedded Steampunk following the 3-tier model and wrappers.

Customers can request missing APIs through the SAP Influence channel: https://influence.sap.com/sap/ino/#/campaign/2759

No changes are made to the signature of an API that are incompatible (requiring adaptation) from a customer point of view. The underlying implementation might change, but the semantics of the interface remain unchanged.

APIs are published on SAP API Business Hub. Alternatively, the list can be displayed in ADT in Eclipse as Released Objects tree (see online documentation Finding Released APIs on SAP Help Portal). See also the SAP Note 3088062 - Identifying local APIs for S/4HANA Cloud.

Default for new APIs is OData v4 based on RAP. All published OData V4 APIs on SAP API Business Hub are based on RAP. It is not planned to migrate all existing OData V2 APIs to V4 in a single effort. This will be an iterative process whenever API changes are required.

Customers should follow the guidelines as laid out in the Extensibility Guide (chapter 6): retire unused code using the custom code management tools, renovate or innovate existing code to be ABAP Cloud compliant.

Yes, customers should follow the guidelines laid out in the new Extensibility Guide.

Authorizations should be set up so that developers use the language version "ABAP for Cloud Development". In addition, ABAP test cockpit checks should be regularly scheduled. Details are explained in the Extensibility Guide.

RAP brings a lot of advantages: reduction of TCD, standardization, stateless model with draft-based context, one business object for several exposure channels, standard programming model for SAP S/4HANA and so on.

Testing after an upgrade especially in private cloud and on-premise deployments are still necessary, but the upgrade effort can be dramatically reduced when adhering to the 3-tier model. In public cloud customers can opt-in for a test upgrade to detect upgrade issues at an early stage.

SAP Fiori is the standard UI technology for tier 1. Key user adaptations also belong to tier 1.

SAP objects which are not released can be wrapped into a custom object (of tier 2) which can be released for cloud development.

Yes, we plan to provide tool support to migrate BOPF based Fiori apps to a RAP compatible model (the result of this migration will be a RAP wrapper).