ABAP Cloud Clean Core Guide: Released APIs, ATC Checks and Safe Wrappers

Original educational visual created for SAP Latest.

Clean core is not simply a rule that says “never write custom code.” It is a development model for keeping extensions upgrade-stable, testable and separated from SAP internals. In ABAP Cloud, that goal is enforced through a cloud-safe language version, released APIs and extension points, and automated checks in ABAP Development Tools and ATC.

Practical rule: Search for a released local API, remote API or extension point first. If none exists, document the gap and use a governed mitigation such as a wrapper only where your SAP edition and clean-core policy permit it.

What ABAP Cloud clean core actually means

ABAP Cloud is SAP’s cloud-ready development model. Its key building blocks are a restricted ABAP language version, released public APIs, Core Data Services, RAP, and ADT. Code that uses only released objects creates a stable contract between custom development and the SAP core. This matters during upgrades because an internal implementation can change without notice, while a released contract has an explicit lifecycle.

• Released local APIs: ABAP interfaces, CDS entities, classes and business object contracts released for local use.
• Released remote APIs: OData, SOAP, events or other integration contracts available through SAP Business Accelerator Hub.
• Released extension points: BAdIs and other enhancement contracts intended for customer implementations.
• Cloud-safe language: ABAP language scope that blocks unsupported statements and direct access to unreleased objects.

Clean-core decision flow

1. Translate the requirement into a business capability, not a technical object name.
2. Search SAP Business Accelerator Hub, released objects in ADT and your system’s API discovery tools.
3. Choose an in-app, developer-extensibility or side-by-side pattern based on data proximity, lifecycle and isolation needs.
4. Implement against released contracts and keep SAP-specific details behind your own interface.
5. Run ATC checks continuously, not only before transport.
6. Record the dependency, release contract and fallback design in the technical documentation.

Example: isolate a released API behind your own interface

The following pattern makes application code easy to test and keeps the SAP dependency in one adapter. Replace the sample interface and method with the released contract available in your system.

INTERFACE zif_pr_service PUBLIC.
  METHODS create
    IMPORTING is_request TYPE zif_pr_types=>ty_request
    RETURNING VALUE(rv_id) TYPE zif_pr_types=>ty_id
    RAISING   zcx_pr_error.
ENDINTERFACE.

CLASS zcl_pr_service_cloud DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_pr_service.
ENDCLASS.

CLASS zcl_pr_service_cloud IMPLEMENTATION.
  METHOD zif_pr_service~create.
    "Map only to the released SAP API available in your release.
    "Keep mapping, messages and commit handling inside this adapter.
    rv_id = zcl_released_pr_adapter=>create( is_request ).
  ENDMETHOD.
ENDCLASS.

How to search for a released object

1. Start with the business noun and action: for example, “purchase requisition create.”
2. Check SAP Business Accelerator Hub for remote APIs and events.
3. In ADT, inspect the API state and release contract of candidate CDS entities, classes and interfaces.
4. Use where-used analysis to confirm that your code does not cross into an internal object.
5. Check the minimum release and cloud availability before selecting the object.

When no released API exists

Do not immediately call an unreleased function module from cloud code. First check whether the requirement can be solved through a released business object, event, key-user extension or side-by-side service. For supported SAP S/4HANA private-edition or on-premise scenarios, SAP documents a mitigation pattern in which an unreleased API is isolated behind a custom wrapper and that wrapper is released for consumption by ABAP Cloud code.

Important: A wrapper does not magically turn an internal API into an SAP-supported API. Your team owns the wrapper, tests, authorization checks, upgrade analysis and change monitoring.

Wrapper boundary checklist

• Expose a small business-oriented interface rather than the entire internal signature.
• Validate input and authorization before the internal call.
• Translate messages into stable custom exceptions or result types.
• Do not leak internal DDIC types across the released custom contract.
• Add ABAP Unit tests around mapping and error handling.
• Run regression tests and ATC after every upgrade or support package.

ATC checks that matter

ATC should be part of the development loop and your transport quality gate. A clean-core-focused variant can identify use of unreleased objects, prohibited language elements, SQL and performance issues, security findings and syntax that is not allowed for ABAP Cloud development.

"Prefer dependency injection so unit tests do not call SAP APIs.
CLASS ltc_app DEFINITION FOR TESTING DURATION SHORT RISK LEVEL HARMLESS.
  PRIVATE SECTION.
    METHODS creates_request FOR TESTING.
ENDCLASS.

CLASS ltc_app IMPLEMENTATION.
  METHOD creates_request.
    DATA(fake_service) = NEW lcl_pr_service_fake( ).
    DATA(cut) = NEW zcl_pr_application( fake_service ).

    DATA(id) = cut->create( VALUE #( description = 'Laptop' ) ).

    cl_abap_unit_assert=>assert_not_initial( id ).
  ENDMETHOD.
ENDCLASS.

Common mistakes

• Searching by table name: this encourages direct table coupling. Search by business capability.
• Suppressing ATC findings: exemptions must have an owner, reason and expiry date.
• Using SAP types everywhere: internal types make the whole application fragile. Map at the boundary.
• Calling COMMIT WORK inside reusable code: transaction ownership should be explicit and match the API contract.
• Assuming released means identical across releases: always verify availability and lifecycle for the target system.

Real-project review checklist

• Is the extension in the correct place: key user, on-stack ABAP Cloud or side-by-side?
• Are all SAP dependencies released for the intended use?
• Can the application layer be unit-tested without an SAP backend call?
• Are authorization, messages, locking and transaction boundaries documented?
• Does CI or the transport process run the agreed ATC variant?
• Is there an upgrade owner for every temporary mitigation?

Interview questions

1. What makes an API safe for clean-core development?
   A documented release contract and supported lifecycle for the intended consumption scenario.
2. Why is a wrapper useful?
   It confines an unstable dependency to one governed boundary and prevents internal types from spreading.
3. Does a wrapper make an unreleased API officially supported?
   No. It is a mitigation owned by the customer and must be monitored and tested.
4. Where does ATC fit?
   During development, CI/quality gates, transport release and upgrade analysis.
5. When is side-by-side extensibility preferable?
   When strong lifecycle isolation, independent scaling or cross-system orchestration is required.

Hands-on exercise

Choose one existing custom report that reads an SAP table directly. Identify the business capability, search for a released CDS entity or API, create a small custom interface, move SAP access into an adapter, write one ABAP Unit test with a fake, then run your clean-core ATC variant. Document any remaining finding and its remediation plan.

Official SAP references

• Developing with ABAP Cloud in the SAP BTP ABAP Environment
• SAP tutorial: mitigate a missing released API
• SAP Business Accelerator Hub

Next reading: Continue with the SAP HANA Cloud Vector Engine guide to learn how semantic search and grounded AI retrieval work close to enterprise data.