ABAP Cloud & the Clean Core Level Concept

Guide for developing with the ABAP Cloud programming model, classifying extensions using the clean core level concept (A–D), and applying clean core principles.

Terminology note: SAP has evolved the former 3-tier extensibility model into the clean core level concept. The 3-tier model (Tier 1/2/3) is superseded — use Levels A, B, C, D instead. Current product naming: SAP Cloud ERP (public), SAP Cloud ERP Private (formerly S/4HANA Cloud Private Edition), SAP Business AI Platform (includes SAP BTP capabilities), SAP Build (pro-code and low-code tooling, includes ABAP Cloud).

Workflow

1. Determine the user's context:

• Understanding ABAP Cloud concepts and restrictions
• Classifying an extension into a clean core level
• Choosing between ABAP Cloud development and classic ABAP development
• Wrapping non-released APIs for use in ABAP Cloud
• Identifying released or classic API alternatives

1. Classify the extension by clean core level:

• Level A: only released APIs and extension points (stability contract)
• Level B: classic APIs and classic frameworks (nominated, no stability contract)
• Level C: SAP internal objects (conditionally clean with changelog)
• Level D: not-recommended objects and patterns (must be remediated)

1. Apply the lowest-level rule: an extension is classified by the lowest level it uses. A Level A extension that calls one internal object is a Level C extension.

1. Guide implementation toward the highest applicable level (Level A first).

Clean Core Level Concept

SAP classifies extensions into four levels, similar to energy labels. Level A is the target state reflecting the "SAP Business AI Platform first" strategy; Level D must be remediated.

Clean core status: Level A = clean core · Levels B and C = conditional clean core · Level D = not clean core.

Level A — Extend with SAP Build and Joule Studio

Only publicly released interfaces and extension points with a stability contract.

• On-stack: ABAP Cloud development model inside SAP Cloud ERP Private, using released local APIs (released CDS views, released BO interfaces, released extension points), plus key user extensibility
• Side-by-side: SAP Business AI Platform using ABAP Cloud, CAP, or low-code/no-code tools (SAP Build, Joule Studio) consuming released remote APIs
• Discover released objects in the SAP Business Accelerator Hub, the Cloudification Repository, or directly in ADT
• Note: Level A coverage does not span the full functional scope of SAP Cloud ERP Private, and full coverage is not planned

"Level A: ABAP Cloud class using only released APIs
CLASS zcl_my_extension DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.
ENDCLASS.

CLASS zcl_my_extension IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    "Released CDS view — no direct table access
    SELECT FROM I_BusinessPartner
      FIELDS BusinessPartner, BusinessPartnerName
      INTO TABLE @DATA(partners)
      UP TO 10 ROWS.
    out->write( partners ).
  ENDMETHOD.
ENDCLASS.

Level B — Leverage classic APIs

Well-established, documented, SAP-nominated classic APIs and classic frameworks. No formal stability contract, but a long history of reliable use and SAP internal quality assurance.

• Typical examples: BAPI_* function modules, CL_GUI_ALV_GRID, non-released BAdIs, user/customer exits, SAP GUI and ALV frameworks
• Custom objects in ABAP language version Standard ABAP are Level B, provided they reference only released or classic objects
• Wrappers around classic APIs that enable consumption from Level A code are Level B
• Identify classic APIs in objectClassifications_SAP.json (Cloudification Repository) and SAP Note 3578329 for framework classification
• Recommended software component for classic ABAP development: HOME

Level C — Access internal objects

SAP internal objects that are technically accessible but not released, not nominated, not documented, and not supported for customer use. This is the default classification for any SAP object not otherwise classified.

• Typical examples: direct calls to internal function modules/classes, read access to SAP database tables
• Mitigation: the changelog for SAP objects identifies internal objects targeted for incompatible changes in upcoming releases, enabling proactive refactoring before upgrades
• SAP may reclassify internal objects as classic (→ Level B) or not recommended (→ Level D)
• Objects with a released successor are flagged internalAPI in the Cloudification Repository

Level D — Not recommended

Highest risk, highest technical debt. Remediate immediately.

• SAP objects classified noAPI in the Cloudification Repository (e.g., RFC_READ_TABLE)
• Modifications to SAP objects (including SAP Notes applied with manual corrections)
• Implicit and explicit enhancements (source code plug-ins)
• Direct write access to SAP database tables
• Calling form routines inside SAP programs
• Critical ABAP statements (kernel calls, system calls, editor calls, EXEC SQL, DB hints, report/Dynpro generation, nametab import/export)
• Implementation of BAdIs flagged as SAP-internal

Development Models

Two coexisting on-stack development models in SAP Cloud ERP Private:

Access rules

ABAP Cloud objects may access only:

• Custom objects inside the same software component
• Released SAP objects (released APIs)
• Custom objects released for ABAP Cloud development (released custom APIs) from a classic software component

Classic ABAP objects should access only:

• Custom objects inside their own software component
• Released SAP APIs and classic SAP APIs
• Custom objects in classic and ABAP Cloud software components

Enforcing the model via authorization

Authorization object S_ABPLNGVS controls whether a developer may create objects in Standard ABAP or only in ABAP for Cloud Development. Use it to create a dedicated ABAP Cloud developer role.

Key Restrictions in ABAP for Cloud Development

• Only released SAP APIs (C1 contract) can be used
• No direct database table access for SAP tables (use released CDS views)
• No classic dynpro, selection screens, or SAP GUI-dependent statements
• No CALL TRANSACTION, SUBMIT, AUTHORITY-CHECK (use CL_ABAP_AUTHORIZATION)
• No classic BAdIs or user exits (only released BAdIs)
• No EXEC SQL or native SQL (use ABAP SQL or AMDP)
• No non-released function modules
• No INCLUDE programs
• No WRITE or classic list output
• Use if_oo_adt_classrun for console output

Wrapper Pattern

When a required API is not released, build a wrapper in a classic ABAP software component and release it for ABAP Cloud development. The consuming ABAP Cloud code stays clean; the wrapper localizes the level violation to a single place.

Wrapper level classification (from the whitepaper):

• Wrapper around a classic API (Level B object) → the wrapper is Level B
• Wrapper around an internal object (Level C object) → the wrapper is Level C
• Wrapper around a not-recommended object → Level D, do not build it

"Classic ABAP software component: wrapper class released for ABAP Cloud
"Wrapping BAPI_PO_CREATE1 (a classic API) → Level B
CLASS zcl_wrapper_material DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_material_reader.
    "Release with C1 contract in ADT → API State tab
ENDCLASS.

CLASS zcl_wrapper_material IMPLEMENTATION.
  METHOD zif_material_reader~get_material.
    "Access non-released API internally
    SELECT SINGLE * FROM mara
      WHERE matnr = @iv_matnr
      INTO @DATA(ls_mara).
    "Map to released structure
    rs_material = VALUE #(
      matnr = ls_mara-matnr
      mtart = ls_mara-mtart
      matkl = ls_mara-matkl ).
  ENDMETHOD.
ENDCLASS.

Wrapper guidance

• CDS views: create a custom CDS view on top of the non-released SAP CDS view and release it. Association targets and value help views may need wrappers too. If no SAP CDS view exists, wrap the database table.
• Classes/interfaces: wrap the non-released FM or class. Do not copy non-released data types — wrap them via TYPES declarations in the wrapper's public section so only the wrapper needs releasing.
• Authorizations: classic APIs often check non-released authorization objects, which cannot be used in ABAP Cloud. PFCG roles can mix released and non-released authorization objects. Provide SU22 data for the wrapper when releasing it and create SU22 variants per designated usage.
• ATC exemptions: wrapping reduces N findings to 1 — create a single fine-grained exemption on the wrapper instead of one per usage. This is SAP's recommended practice for internal objects.
• Retire wrappers: once SAP releases the API, replace the wrapper and move the code to ABAP Cloud.

Wrapper via RFC Proxy (side-by-side to on-stack)

"Side-by-side consumer calls a released RFC wrapper
DATA(lo_dest) = cl_rfc_destination_provider=>create_by_comm_arrangement(
  comm_scenario  = 'Z_MY_COMM_SCENARIO'
  service_id     = 'Z_MY_OUTBOUND_SRV' ).

CALL FUNCTION 'Z_WRAPPER_FM'
  DESTINATION lo_dest->get_destination_name( )
  EXPORTING iv_param = lv_value
  IMPORTING ev_result = lv_result.

Object Classification Discovery

Classic API classifications are provided for these object types: function modules (FUNC), classes (CLAS), interfaces (INTF), CDS views (STOB), BO interfaces (BDEF). DDIC objects used as data types are not classified or checked; only SQL access to SAP tables is checked.

Common Non-Released → Released Replacements

Use Case → Level Mapping

Key User vs. Developer Extensibility

Both are Level A when they use released extension points:

• Key user extensibility (no/low code): custom fields, custom logic, custom CDS views, custom business objects, custom analytical queries via Fiori apps. Start here for tightly coupled extensions — use transaction SEEA / the extension registry to find registered extension points.
• Developer extensibility (ABAP Cloud): use when key user extensibility is too limited. Full lifecycle in ADT with RAP.

Best Practices

1. Target Level A — "SAP Business AI Platform first", ABAP Cloud for on-stack
2. Classify by the lowest level used — one internal object makes the whole extension Level C
3. Eliminate Level D immediately — modifications, implicit enhancements, table writes, noAPI objects
4. Minimize Level C — replace internal objects with released or classic APIs; monitor the changelog for SAP objects
5. Accept Level B pragmatically — classic APIs are upgrade-stable in practice; do not force unnecessary rewrites
6. Wrap, don't scatter — one wrapper with one ATC exemption beats many direct usages
7. Govern with ATC — global check variant, block transport release on priority 1 and 2 findings
8. Separate software components — ABAP Cloud component vs. HOME for classic

Output Format

When helping with ABAP Cloud / clean core topics, structure responses as:

## ABAP Cloud Guidance

### Context

- Clean core level: [A / B / C / D] (classified by the lowest level used)
- Development model: [ABAP Cloud / Classic ABAP]
- Language version: [ABAP for Cloud Development / Standard ABAP]
- Target platform: [SAP Cloud ERP / SAP Cloud ERP Private / SAP Business AI Platform]

### Recommendation

[Guidance on the approach and how to reach a higher level]

### Code Example

[ABAP code following clean core principles]

### Released API References

- [List of relevant released or classic APIs used]

### Expected ATC Findings

- [Priority and check name, if any]

References

• Clean Core Extensibility Whitepaper (level concept): https://www.sap.com/documents/2023/11/2e6b5b98-957e-001e-9e9e-cbd0b2b1f1e0.html
• Extend SAP S/4HANA with ABAP-based extensions (guide): https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/extend-sap-s-4hana-in-the-cloud-and-on-premise-with-abap-based-extensions/ba-p/13500561
• SAP Cloudification Repository: https://github.com/SAP/abap-atc-cr-cv-s4hc
• Cloudification Repository Viewer: https://sap.github.io/abap-atc-cr-cv-s4hc/
• SAP Business Accelerator Hub: https://api.sap.com/
• ABAP Cloud Cheat Sheet: https://github.com/SAP-samples/abap-cheat-sheets
• Clean Core Guidelines: https://help.sap.com/docs/abap-cloud
• SAP Note 3578329 — classic technology classification
• SAP Note 3565942 — clean core ATC checks

Detailed Reference

• Clean core level details: Read references/clean-core-levels.md for a full level-by-level comparison, decision matrix, governance setup, and remediation priorities

Related Skills

• abap-cloud-migration: Use for level-based remediation of existing custom code
• atc-cloudification: Use for configuring ATC clean core checks and level governance
• released-abap-classes: Use for finding Level A released API alternatives
• authorization-iam: Use for authorization in ABAP Cloud and wrapper SU22 handling
• badi-enhancement: Use for level classification of BAdIs and enhancement techniques