Clean Core

The problem it solves

In classic ECC projects, years of direct table modifications, user-exits and modified standard code turned every upgrade into a high-risk project. Clean Core forbids that pattern by design: modifications only happen through released, stable APIs that SAP guarantees not to break.

The extensibility pyramid

SAP organises extension options from least to most invasive. As a rule, always pick the option lowest on this list that solves the requirement:

• Configuration — customizing, no code at all.
• Key user extensibility — custom fields, custom logic and custom CDS views built through Fiori apps, no ABAP required.
• In-app (developer) extensibility — RAP-based extensions running inside S/4HANA, but restricted to released APIs only.
• Side-by-side extensibility — a separate app on SAP BTP (CAP or ABAP Environment) that talks to S/4HANA only through public APIs, fully decoupled from the core.

Released objects: the technical enforcement

Every CDS view, class or function module in S/4HANA is tagged with a release contract. The ABAP Development Tools will flag — and, in Steampunk, block — any reference to an object that isn't officially released for custom use.

@API.state: #RELEASED
@API.releaseState.since: '2408'
define view entity API_CONTRACT_MANAGER
  as select from ZI_CONTRACT_MANAGER
{
  key ContractId,
      ContractManager1
}
// consuming this API is Clean Core-safe: SAP guarantees its stability

What this means day to day

• No direct table access — always go through a released CDS view or API, never SELECT straight from a standard table.
• No modifications to standard objects — enhancements happen via BAdIs, enhancement spots or RAP's own extension mechanisms, never by changing SAP's code.
• Prefer BTP for anything non-core — reporting, integrations and custom UIs that don't strictly need to live inside S/4HANA belong on BTP.