ABAP Cloud and the Released API Model

ABAP Cloud is SAP's programming model for writing custom code that only touches objects SAP has formally released for external consumption. It combines two separate restrictions that people constantly conflate: a language version restriction (a cut-down ABAP syntax with no direct table access via native constructs, no obsolete statements) and an API restriction (you may only reference classes, CDS views, function modules or BAdIs that carry a release contract). The structural fact that explains most confusion: these two restrictions are enforced at different layers. The language subset is a compiler/kernel setting attached to the ABAP language version of the package. The API restriction is a metadata check done by the syntax checker and ATC, looking at whether the target object's release contract covers the calling context. Code can be perfectly valid ABAP Cloud syntax and still fail because it calls an unreleased object, or vice versa.

Use ABAP Cloud for any new development targeting S/4HANA Cloud public edition, the BTP ABAP environment, or any private cloud/on-premise landscape being run under a clean-core policy. It is the right tool when the requirement is a genuine coded extension, not something a key-user configuration tool can already do, and when the business object involved has released APIs to build against. It is the wrong reach when the object you need is not released at all yet, in which case forcing the code into an ABAP Cloud package just produces syntax errors with no workaround; the honest answer there is key-user extensibility, a released alternative object, or a formal request for SAP to release the needed interface. It is also the wrong tool for quick, throwaway diagnostic code in an on-premise system where classic access is still permitted and faster.

Below ABAP Cloud sits the ABAP language runtime and the kernel-level language version switch that enforces the restricted syntax. Above it sit the two consumption channels: in-app extensions built as classes and CDS views inside the managed system, and side-by-side extensions built in the BTP ABAP environment calling back in through released remote APIs. ABAP Cloud supersedes the classic extensibility approach of implicit enhancements, direct SELECTs on any transparent table, and calls into unreleased function modules or internal classes. It does not replace key-user extensibility (custom fields, custom logic via simple expression editors); that remains a parallel, lower-code path for business users and sits alongside rather than under ABAP Cloud. Packages and software components are the mechanism that ties an object to this model — assigning a package to a cloud-enabled software component is what actually switches on both restrictions.

A developer building an extension on S/4HANA Cloud public edition needs to read sales order header data and trigger a follow-up action once a custom condition is met. The instinct is to select directly from the sales order database table and call an internal function module used by the standard order flow. Both fail the syntax check the moment the class's package is assigned to a cloud-enabled software component: the table has no release contract for direct access, and the function module is marked as internal. The fix is to find the released CDS view exposing sales order data for consumption, and the released business object API or BAdI meant for this kind of extension point, rather than the internal implementation the standard app happens to use. The class is rewritten to select from the released CDS entity and to implement the released extension interface. Once every call resolves to a released object, the syntax check passes cleanly, and the class can be transported and, if built in the BTP ABAP environment, deployed as a side-by-side app calling back through a released remote-enabled API.

ABAP Cloud is mandatory in S/4HANA Cloud public edition and in the BTP ABAP environment; there is no classic fallback in those environments. In S/4HANA private cloud and on-premise, classic extensibility is still technically available, but SAP's clean-core guidance discourages it for new development, and increasingly steers custom builds toward released APIs even where the older path still compiles. Existing custom code built on internal objects does not need to be rewritten overnight, but any new extension, and any code touched during a conversion or upgrade project, is the natural point to move onto released APIs rather than add to the pile of tightly coupled custom code that makes the next upgrade harder.

The developer writes to the release contracts and resolves syntax and ATC findings. The architect decides which extension model an object belongs in — side-by-side, in-app cloud, or classic — and sets up the package and software component accordingly. The functional consultant confirms whether the standard object genuinely needs extending before any of this starts. Handover includes the package assignment, ATC results, and a list of the released APIs actually consumed.

Read clean-core-explained-for-abap-developers for the policy reasoning behind this model, and key-user-extensibility-versus-developer-extensibility to decide whether code is even the right tool before reaching for ABAP Cloud. Custom-fields-and-logic-in-s-4hana covers one of the most common extension types built this way. Atc-checks-in-an-s-4hana-conversion explains the enforcement tooling referenced above, and custom-code-migration-for-s-4hana covers moving existing classic code toward released APIs.