1.2Bloom · AnNot started

Extensibility approaches and clean-core levels (A–D)

Reading depth

What you'll learn

Three extensibility approaches — Key User (in-app), Developer (on-stack ABAP Cloud), Side-by-side (BTP) — and a separate cleanliness scale, Levels A (released/stable) to D (modifications/table writes); use the lowest-effort approach and aim for Level A.

  • Three approaches (not tiers): Key User (in-app low-code, on-stack), Developer (pro-code on-stack ABAP Cloud / Embedded Steampunk), Side-by-side (decoupled on BTP).
  • Side-by-side is a cleanest-core option for a separate lifecycle/runtime — not the 'worst' last resort.
  • Clean-core levels (Aug 2025): A = released/stable APIs (on-stack or BTP), B = released classic APIs too, C = accesses SAP internal objects, D = modifications/table writes/implicit enhancements (not clean).

SAP describes extensibility as three approaches (types, not numbered tiers), split on two axes: where the code runs (on-stack inside S/4HANA vs side-by-side on SAP BTP) and, for on-stack, which toolset. Key User Extensibility is the low-code, in-app on-stack option — custom fields, custom CDS, and custom logic at released enhancement points, no classic development. Developer Extensibility is pro-code on-stack ABAP Cloud (Embedded Steampunk) in a cloud-enabled software component. Side-by-Side Extensibility runs decoupled on SAP BTP (ABAP environment, Java, Node, Python) over released OData/RAP/events. Pick the lowest-effort approach that meets the requirement; side-by-side is a cleanest-core option (used when you need a separate lifecycle or runtime), not a 'worst' last resort.

Cleanliness is graded separately, on the Aug-2025 clean-core compliance scale of four levels. Level A ('Extend with SAP Build') uses only publicly released, stable interfaces backed by stability contracts — covering both on-stack ABAP Cloud and side-by-side BTP — and is the gold standard. Level B ('Leverage classic APIs') meets Level A's criteria but also uses SAP's released, documented classic APIs (BAPIs etc.); upgrade-stable and still clean. Level C ('Accesses internal objects') is partially compliant — it reaches SAP internal objects not released for customer use (a grey zone for legacy scenarios). Level D ('Not recommended extensions') is not clean: non-recommended objects, modifications, write access to SAP tables, and implicit enhancements — the highest risk and technical debt.

For context: SAP's earlier '3-tier extensibility model' (TechEd 2024, for S/4HANA Cloud Private Edition and on-premise) named Tier 1 = ABAP Cloud (both key-user and developer extensibility), Tier 2 = Cloud API enablement (released classic APIs/wrappers for objects not yet released for Tier 1), and Tier 3 = classic ABAP. Side-by-side on BTP was a separate, clean column at the Tier-1 level — never Tier 3. SAP evolved that binary model into the A–D levels in August 2025; the 3-tier model lives on mainly as the ABAP_CLOUD_DEVELOPMENT_3TIER ATC variant for Private-Edition custom-code migration.

Key points

  • Three approaches (not tiers): Key User (in-app low-code, on-stack), Developer (pro-code on-stack ABAP Cloud / Embedded Steampunk), Side-by-side (decoupled on BTP).
  • Side-by-side is a cleanest-core option for a separate lifecycle/runtime — not the 'worst' last resort.
  • Clean-core levels (Aug 2025): A = released/stable APIs (on-stack or BTP), B = released classic APIs too, C = accesses SAP internal objects, D = modifications/table writes/implicit enhancements (not clean).
  • Pick the lowest-effort approach that meets the requirement; aim for Level A.
  • Legacy context: the old 3-tier model (Tier 1 ABAP Cloud, Tier 2 Cloud API enablement, Tier 3 classic ABAP) was evolved into Levels A–D in Aug 2025.

Examples

Choosing an approach

Add a field to a Fiori app → Key User extensibility. Build a transactional app over a Z table → Developer extensibility (on-stack ABAP Cloud). Build a heavy custom service with its own lifecycle → Side-by-side on BTP. All three can be Level A when they stay on released, stable APIs; writing to an SAP table or modifying standard is Level D.

Source notes: clean-core-curriculum §1.2

Ask Claude

Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.