abap-clean-coreApply SAP Clean Core extensibility principles whenever the user writes, reviews, refactors, or designs ABAP code for SAP S/4HANA — any deployment (Public Cloud, Private Cloud, on-premise). Use this skill any time the conversation involves ABAP extensions, custom Z-code, BAdIs, BAPIs, user exits, CDS views, RAP services, custom fields or business objects, mo…
Independent GitHub snapshot · Automated classification · Original documentation governs
This skill encodes SAP's official Clean Core extensibility framework. Apply it when guiding the user through ABAP development, code review, refactoring, or architecture decisions for SAP S/4HANA.
None — this is a knowledge skill: it needs no SAP connection and works in any
ABAP conversation. When sap-adt-mcp is connected it gets sharper:
adt_run_atc / adt_run_atc_package verify findings against the system's real
check variant, adt_list_released_apis confirms what is actually released on
that release level, and adt_where_used measures the blast radius of a Level
C/D dependency before recommending a replacement. Cloud-readiness ATC checks
require an S/4HANA system (or a recent ATC content update on NW 7.5x).
Every extension that touches SAP-internal objects, modifies standard code, or relies on undocumented APIs becomes a maintenance liability. It blocks upgrades, breaks unpredictably, and accumulates as technical debt that compounds over years.
Clean Core is the discipline of building extensions that survive SAP upgrades automatically — by isolating custom code from the standard through stable, released interfaces. It's not theoretical: SAP's entire cloud strategy (RISE, GROW, S/4HANA Cloud) assumes customer extensions are decoupled. Code that ignores Clean Core is code that will eventually be rewritten.
Clean Core spans five principles — Processes, Data, Integration, Operations, and Extensibility. This skill focuses on Extensibility (the code and architecture side), but be aware: when a user asks about "clean core data" or "clean core integration," they're asking about the other four principles, not about extensions.
When you help with ABAP, your job is to nudge the user toward extensions that will still work after the next upgrade — without lecturing, without refusing classic-ABAP work when it's needed, but always making the trade-off visible.
All clean core work falls into one of two efforts. Naming which one the user is in helps frame the advice.
Applies to new development. The goal is zero unnecessary debt: every new extension at the highest achievable level, governed by a process that catches violations before they ship. When the user is writing or designing something new, you're in Stay Clean mode — enforcement-heavy, with quality gates blocking transport on Level 1–2 ATC findings.
Applies to existing custom code. Realistic, prioritized reduction over years — eliminate Level D first ("Level D zero" is a year-one goal), then chip away at C and B. When the user is reviewing legacy or planning remediation, you're in Get Clean mode — prioritization-heavy, with tactics like the boy scout principle (every developer leaves code cleaner than they found it), the lighthouse approach (clean during major rework anyway), and a 10% annual reduction target.
For the full Stay Clean / Get Clean playbook, KPI calculations, and exemption process, see references/governance.md.
Every ABAP extension sits in exactly one of four "cleanliness levels." Identifying the level — and pushing it upward when possible — is the entire framework.
Examples: released CDS views, business object interfaces, released BAdIs, RAP services, OData APIs documented in the SAP Business Accelerator Hub, custom fields via the Custom Fields app or extension framework.
BAPI_PO_CREATE1), released user exits, classic ALV grid (CL_GUI_ALV_GRID), traditional Web DynproUse Level B when no Level A equivalent exists. Whenever possible, wrap Level B calls in a Level A ABAP Cloud wrapper so the rest of the codebase stays clean.
classic (better) or noAPI (worse) at any releaseWhen unavoidable, mitigate by:
MARA, VBAK, BSEG, etc.)noAPI in the Cloudification RepositoryLevel D is the top refactoring priority. Treat any new Level D code in code review as something that needs explicit, time-bound justification.
For deep-dive on Cloudification Repository state values (released, classic, internal, noAPI, internalAPI with successor), released local vs remote APIs, reclassification dynamics, and per-anti-pattern remediation, see references/levels-detailed.md.
Two layers: fit-to-standard first, then the SAP Application Extension Methodology if extension is justified.
Before deciding how to extend, decide whether to extend at all:
Many "we need an extension" conversations should pause here. Building custom code for something the standard already does is the most common form of unnecessary technical debt.
Once an extension is justified, the official methodology structures the technology choice:
Default to side-by-side. Choose on-stack only when one of these is true:
If neither applies clearly, side-by-side is the right answer. If both apply, you have a hybrid candidate (on-stack ABAP service exposing a released remote API, consumed by a side-by-side BTP UI/orchestration layer).
For the full decision matrix, on-stack vs side-by-side criteria, hybrid deployment patterns, and worked scenarios, see references/decision-framework.md.
Default to ABAP Cloud syntax and patterns:
SELECT chains on SAP standard tablesNEW, VALUE, FOR, REDUCE)ABAP Cloud is enforced at the compiler level — code that violates the rules doesn't compile. There's no escape hatch. For the explicit allowed/forbidden lists, prebuilt services available without extra license (logging, change docs, number ranges, jobs, currency, UOM, factory calendar, XLSX), and core building blocks (RAP, CDS, business object interfaces, Custom Fields), see references/abap-cloud-rules.md.
Flag clearly with the level. Tone: descriptive, not judgmental.
Likely Level D — flag as error:
UPDATE / INSERT / MODIFY on SAP standard tablesENHANCEMENT-POINT ... INCLUDE BOUND patterns)noAPI objects from the Cloudification RepositoryLikely Level C — flag as warning:
SELECT from SAP standard tables that have a released CDS view equivalentCALL FUNCTION to internal (non-released) function modulesTYPE REF TO to SAP internal classesLikely Level B — flag as informational:
Pattern 1 — Wrap a classic API to expose Level A surface:
" Anti-pattern: BAPI called directly from cloud-namespace code
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
poheader = ls_header
TABLES
poitem = lt_items
return = lt_return.
" Better: wrap in a released-style local API
CLASS zcl_po_service DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES zif_po_service.
ENDCLASS.
CLASS zcl_po_service IMPLEMENTATION.
METHOD zif_po_service~create.
" BAPI call lives here, isolated.
" Callers consume only the released interface — Level A from their perspective.
ENDMETHOD.
ENDCLASS.
The dependency on the BAPI (Level B) is now localized. Consumers stay at Level A. When a successor RAP-based equivalent appears, you change one file.
Pattern 2 — Replace internal table read with released CDS view:
" Anti-pattern: direct SELECT on internal SAP table
SELECT matnr, mtart, ersda
FROM mara
INTO TABLE @DATA(lt_materials)
WHERE mtart = 'FERT'.
" Better: use released CDS view (lookup in Business Accelerator Hub)
SELECT material, materialtype, creationdate
FROM i_product
INTO TABLE @DATA(lt_materials)
WHERE materialtype = 'FERT'.
The released view (I_* namespace pattern is common) carries SAP's stability contract. Field renames during upgrades become SAP's problem, not yours.
Pattern 3 — Replace modification with extension point:
When you find a modification of SAP standard:
Respect the constraint. Deliver the working code. But:
VBAK are not upgrade-safe"The user is the engineer of record. Your job is to make the trade-off visible, not to override it.
Four KPIs make clean core progress quantifiable. Reach for these when the user asks "how is the system doing?" or wants to set targets.
SMODILOG. Direct count of Level D modifications.For calculation details, governance practices, and the exemption process, see references/governance.md.
released (A), classic (B), internal (C, default), noAPI (D), and internalAPI (with successor — points you to the released replacement).When you see these in code under review, name the pattern and the level:
| Symptom in code | Likely level | First-line fix |
|---|---|---|
MODIFY mara FROM ... | D | Use Custom Fields framework or business object interface |
CALL FUNCTION 'BAPI_*' in new code | B | Wrap in Level A class |
SELECT ... FROM <SAP standard table> | C (often) | Find released CDS view in Business Accelerator Hub |
ENHANCEMENT-POINT ... INCLUDE BOUND (implicit) | D | Use released BAdI / extension point |
| Modification key dialog appears | D | Stop; find an extension point |
| New SE38 report | B (classic) | Use Fiori + RAP |
| New Web Dynpro | B (classic) | Use SAPUI5 / Fiori Elements |
TYPE REF TO CL_<internal> | C | Find released class or use released business object |
| Custom Z-table written from custom code | A | Fine — your own namespace |
| Custom field on SAP entity via append structure | D (often) | Use Custom Fields app (key user extensibility) |
references/levels-detailed.mdreferences/decision-framework.mdreferences/governance.mdreferences/abap-cloud-rules.md