The Clean Core strategy is an architectural design principle that keeps the SAP standard ERP core software free of custom modifications. Custom extensions are developed either "in-app" using key-user extensibility or "side-by-side" on SAP BTP, part of the SAP Business AI Platform. This decoupling lowers upgrade risk and technical debt: extensions built on released interfaces are far less likely to break on an upgrade, though each upgrade still needs its compatibility and regression testing.
Knowledge Hub
Clean Core & Extensibility Reference Hub
Discover the technical architectures, security guidelines, and extensibility patterns aligned with SAP's published Clean Core guidelines for S/4HANA.
Naming note: the platform for side-by-side extensions is SAP BTP, part of the SAP Business AI Platform. SAP presented that portfolio at Sapphire 2026; it bundles SAP BTP, AI Foundation, SAP Business Data Cloud and SAP HANA Cloud. SAP BTP keeps its name inside it, and so do the concrete services — SAP shipped releases under the name “SAP BTP ABAP environment” as recently as August 2026. We use SAP's own names for the services and SAP BTP for the platform around them.
Quick Answer
SAP Clean Core is a set of guiding principles for keeping the S/4HANA core standard and upgradeable across five dimensions — business processes, extensibility (custom code), data, integration, and operations. A Clean Core assessment measures maturity across those dimensions. For the extensibility dimension specifically it means getting object-level visibility into custom ABAP (what touches standard tables or unreleased objects) and attaching KPIs — a Clean Core Score (Clean-Core.io's own 5–100 measure, higher is better — not SAP's Technical Debt Score, which runs the other way) and an A–D readiness grade — a lookup in SAP’s published object data for SAP objects, an estimate for your own Z/Y objects — so the highest-risk objects are remediated first. It is complementary to SAP ADT/ATC and the SAP toolchain (Cloud ALM, LeanIX, Signavio), which remain the authoritative checks.
Frequently Asked Questions
Structured architectural explanations for developers and crawler extraction
In-App RAP (ABAP RESTful Application Programming Model) runs directly within the S/4HANA tenant. It is ideal for extending standard SAP business objects and UI layers using native ABAP in a cloud-compliant way. Side-by-Side CAP (Cloud Application Programming Model) runs externally on SAP BTP, typically using Node.js or Java. It is designed for standalone cloud-native applications, multi-tenant SaaS products, and integration with non-SAP systems, fully decoupling execution from the ERP core.
Clean-Core.io does not configure anything in your SAP BTP subaccount or S/4HANA tenant. The usual security pattern for a side-by-side extension is JSON Web Tokens (JWT) validated by the SAP XSUAA (Extended Services for User Account and Authentication) service for stateless API calls with role-based access control (RBAC), and the SAP Connectivity and Destination services routing RFC and OData traffic via SAP Cloud Connector without exposing internal endpoints. Setting that up in your tenant is your team's work; the app provides analysis, design drafts and a read-only connection check, not the deployment.
BYOT lets a developer connect their own non-production S/4HANA sandbox to check the connection, read OData metadata and make one read-only call against a real service. Running the generated tests against the tenant is locked until the isolated live runner has passed its review; tests run against mocks in the isolated test runner. It is read-only, credentials are encrypted at rest (AES-256-GCM) in a server-only store, production endpoints are blocked, and every connection is admin-gated (manually reviewed and approved) before activation. Clean-Core.io does not host or persist your ERP data — SAP transaction data is processed statelessly in memory. The feature is free; access is granted by an administrator, not by paying for a tier.
A deterministic engine reads the custom ABAP before any language model does. It reconstructs the business process as BPMN, with a line anchor on every element or the reason it has none, lists the business rules hard-coded in the program, and grades each SAP object the code uses Level A–D from SAP's published Cloudification Repository, or marks it Unknown where the repository holds no answer for it. The Management view then asks for one decision: keep, rebuild, move to SAP standard or retire. Design, Transformation and Testing carry the same evidence to a target design, a code draft in ABAP Cloud (RAP) or CAP, and test scenarios, each marked as a Model proposal for an architect to review, and every completed analysis is stored as a signed run. It complements SAP's own tooling and does not replace human judgment.
Key Terms
A quick glossary mapping technical SAP terms to modern integration architectures:
- SAP BTP
- The integration and extension platform for SAP applications. It enables the development of side-by-side extensions, data orchestration, and custom cloud-native business processes separate from the ERP core. Since SAP Sapphire 2026 it is part of the SAP Business AI Platform, the portfolio that bundles SAP BTP, AI Foundation, SAP Business Data Cloud and SAP HANA Cloud; SAP BTP keeps its name, and so do its services, such as the "SAP BTP ABAP environment".
- SAP Cloud Connector
- A secure software link that runs inside the customer's on-premise or private cloud network, establishing an encrypted TLS connection to SAP BTP without requiring complex inbound firewall configurations.
- OData (Open Data Protocol)
- An OASIS standard protocol defining best practices for building and consuming RESTful APIs. It is the default communication standard for SAP S/4HANA business services.
- CDS (Core Data Services)
- The data modeling infrastructure used by SAP. CDS views define database tables, relationships, and service projections declaratively inside both the ABAP environment (RAP) and the Node.js/Java environment (CAP).
Extensibility Paradigm Comparison
Decision framework comparing the RAP route on SAP S/4HANA and the CAP route on SAP BTP
| Feature / Criteria | In-App RAP (ABAP RESTful) | Side-by-Side CAP (SAP BTP) |
|---|---|---|
| Runtime Environment | In-App RAP (ABAP RESTful)Directly inside SAP S/4HANA (ABAP stack) | Side-by-Side CAP (SAP BTP)SAP BTP (Node.js, Java, Cloud Foundry/Kyma) |
| Primary Use Case | In-App RAP (ABAP RESTful)Modifying/enhancing standard SAP business logic | Side-by-Side CAP (SAP BTP)Standalone apps, partner SaaS, multi-system integration |
| Development Languages | In-App RAP (ABAP RESTful)Modern ABAP (Cloud-enabled subset) | Side-by-Side CAP (SAP BTP)JavaScript, TypeScript, Java |
| Database Access | In-App RAP (ABAP RESTful)Native SQL on HANA via CDS views | Side-by-Side CAP (SAP BTP)OData, REST, or database targets (HANA, PG, SQLite) |
| Core Decoupling | In-App RAP (ABAP RESTful)High logical coupling (shares SAP memory) | Side-by-Side CAP (SAP BTP)Complete architectural separation (connected via APIs) |
| Upgrade Impact | In-App RAP (ABAP RESTful)Low (released SAP APIs stay stable; regression tests still needed) | Side-by-Side CAP (SAP BTP)Low (runs separately; the APIs it calls still need testing) |
How Clean-Core.io applies this to one ABAP program
The extensibility dimension, one program at a time, on one chain of evidence:
- Process: the business process read from the code as BPMN, with a line anchor on every element or the reason it has none, and the business rules hard-coded in the program.
- Level A–D: each SAP object the code uses, graded from SAP's published Cloudification Repository and object classification under a versioned rule, or marked Unknown where neither holds an answer — an orientation; ABAP Test Cockpit stays the authority.
- Decision: keep, rebuild, move to SAP standard or retire, in the Management view, recorded by the signed-in account.
- Design, code draft, tests: on the same evidence, each a Model proposal for a person to review.
- Signature: every completed analysis is stored as an immutable run signed by the server.