In SAP S/4HANA, managing custom code efficiently is key to staying agile and upgrade-ready. SAP's Clean Core Extensibility introduces a pragmatic 4-level model (A-D) that simplifies how we qualify and manage extensions.
This is especially relevant for SAP S/4HANA Cloud Private Edition and on-premise systems, where classic ABAP objects are still widely used.
Unlike the rigid "clean vs. unclean" binary, this model offers a nuanced, risk-based approach, evolving from the old 3-tier system to help you assess extension quality, upgrade stability, and alignment with clean core principles.
Think of it like energy efficiency labels on appliances:
Level A is your top-tier, eco-friendly option (low risk, high efficiency), while Level D is the outdated energy guzzler (high risk, big technical debt).
The goal?
Prioritize higher levels (A first, then B, then C) for a "BTP-first" strategy, decoupling extensions from SAP's core for seamless upgrades.
Let's break it down level by level, with simplifications and tips for real-world application.
Level A: Extend with SAP Build – The Gold Standard for Compliance
This is the pinnacle of clean core, fully compliant extensions built only on publicly released, stable interfaces with formal stability contracts from SAP. No guesswork; everything is documented and upgrade-safe.
-
Side-by-Side: Develop on SAP Business Technology Platform (BTP) using pro-code (e.g., ABAP, Java, JavaScript) or low-code tools for apps and process automation.
-
On-Stack: Build directly in SAP S/4HANA Cloud using the ABAP Cloud development model and publicly released APIs.
Simplified Explanation:
If your development uses the ABAP language version "ABAP for Cloud Development" and sticks to released APIs (or wrappers for non-released ones, think of wrappers as secure "adapters" for missing APIs), it's Level A.
Why It's Great: Zero upgrade headaches, perfect for future-proofing.
Example: Creating a custom workflow app on BTP that integrates with S/4HANA via stable APIs.
Tip: Start here for new projects; use SAP Build for quick, low-code wins.
Level B: Leverage Classic APIs – Reliable and Documented for Legacy Needs
For when Level A isn't enough, Level B lets you tap into SAP's classic APIs and technologies. These are well-defined, documented interfaces that are generally upgrade-stable (based on SAP expert nominations, not formal contracts).
Simplified Explanation:
Your code qualifies if it uses classic APIs (plus released APIs) from SAP's list.
Check the full roster here: Cloudification Repository Viewer. Note: This list also flags "noAPI" items (avoid those, they're Level D).
Why It's Useful: Balances flexibility with stability for complex scenarios. Example: Wrapping a classic BAPI like BAPI_PO_CREATE1 in a custom extension for procurement processes.
Tip: Use ABAP Test Cockpit (ATC) to validate - Level B shows as an "info" message. Monitor for successors (e.g., a released API) to upgrade to Level A.
Level C: Access Internal Objects – Flexible but Conditional for Legacy Code
Level C covers partially compliant extensions relying on SAP's internal objects (not officially released or supported). These offer wiggle room for legacy needs but come with risks - no guarantees on documentation, stability, or long-term support.
Simplified Explanation:
If your code uses standard SAP objects not in the released/classic lists (check SAP's GitHub repo), it's Level C.
SAP's changelog helps spot incompatible changes early for proactive upgrades.
Technically, the changelog information is transferred via the Simplification Database infrastructure from the SAP Support Portal to your system. You download the Simplification Database file containing the changelog data from the SAP Software Download Center of the SAP Support Portal and import it via transaction SYCM into your system.
Check out Extensibility Guide for details.
Why It's "Conditional": It's common in old code, but SAP provides changelog information via Simplification Database infrastructure to assess risks before upgrades.
Example: Reading from an internal function module in a legacy report.
Tip: ATC flags these as warnings. Regularly review the changelog and refactor toward Levels A/B. Analogy: It's like using an off-label tool, handy, but check for "recalls" (changes) often.
Level D: Not Recommended Extensions – High-Risk Debt Creators
Avoid this level, it's for extensions using explicitly non-recommended objects or techniques, creating the highest upgrade risks and technical debt.
Simplified Explanation:
Code here involves "noAPI" objects (from the Cloudification Repository), modifications to SAP objects, direct writes to SAP tables, or implicit enhancements. These are flagged as errors in ATC.
Why It's Problematic: It ties your code too tightly to SAP's internals, leading to breakage during updates. Example: Directly modifying an SAP table or using implicit enhancements.
Tip: Prioritize eliminating Level D first, refactor to higher levels. ATC will block transports with these errors unless exempted (use sparingly for governance).
Why SAP Evolved Clean Core: From Rigid Rules to Real-World Flexibility
SAP's Clean Core concept has been a hit in the market, it's all about decoupling custom extensions from core SAP code to keep upgrades smooth and stable. But the old 3-tier extensibility model? It was a bit too strict for many users.
Let's dive into why SAP made the switch to the more nuanced 4-level model, based on insights from their latest guidelines.
The 3-tier model pushed hard for "clean" extensions:
-
Build everything using publicly released APIs.
-
Use SAP BTP for side-by-side apps or ABAP Cloud for on-stack ones.
-
Stick to technologies available in the public cloud (Tier 1 only).
While this approach made sense in theory, it didn't account for the real world. Many companies have massive portfolios of legacy custom code built on classic ABAP technologies. Even new extensions often rely on these older tools.
The problem?
The model applied a one-size-fits-all "clean vs. unclean" label, ignoring that not all classic code is equally risky.
The Key Issue: Not All Risks Are Created Equal
In practice some classic patterns like using ABAP List Viewer are super stable and pose minimal upgrade risks. Labeling them all as "unclean" felt unfair and unhelpful.
This binary view failed to reflect the full spectrum of risks, making it tough for teams to prioritize fixes or manage hybrid setups blending old and new tech.
Wrapping It Up: Why This Matters
SAP's 4-level model focuses on transparency and practical solutions, not perfection. This is especially helpful when you're mixing old classic ABAP code with new cloud technologies.
Here's your strategy:
| Clean core level | SAP objects qualifier | Usage | ABAP test cockpit behavior |
| Level A | [Released] SAP remote APIs, SAP local APIs and SAP extension points | Go-to choice (Use SAP BTP First) | No finding |
| Level B | [Classic] SAP extension points and SAP APIs | Okay for existing legacy code | Priority 3 finding (information message) |
| Level C | [Internal] SAP objects | Okay for existing legacy code | Priority 2 finding (warning message) |
| Level D | [not recommended] SAP objects and extension point / technology | Elimitate ASAP | Priority 1 finding (error message) |
For detailed documentation, please check the blog - ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud.
