Lesson 3 of 5
Extensibility and the clean core
8 min
Configuration covers most requirements. The rest need extensions: a custom field, a validation, a report, an app or an integration that SAP does not deliver. How you may extend the system is the second big difference between editions, and it has the most direct effect on upgrade testing.
Three extension styles
| Style | What it is | Who builds it | Public Edition | Private / on-premise |
|---|---|---|---|---|
| Key user (in-app) | Custom fields, custom logic, adapted forms and UIs, custom analytical queries, using Fiori tools | Key users and business experts | Yes | Yes |
| Developer (on-stack) | ABAP Cloud code inside S/4HANA using only released APIs and extension points | Developers | Yes | Yes |
| Side-by-side | Separate apps on SAP Business Technology Platform connected through released APIs and events | Developers | Yes | Yes |
| Classic ABAP | User exits, classic BAdIs, custom programs reading SAP tables, modifications of SAP code | Developers | No | Yes, but against clean core guidance |
The first three styles exist in every edition and are built on interfaces SAP has released and promises to keep stable. The fourth exists only where the customer controls the system, and it is where upgrade risk lives. Contoso's ECC system had several hundred custom objects. Moving to Private Edition, the program could have carried all of them over. Instead, Grace's PMO asked for each one: still used? replaceable by standard? rebuildable on released interfaces?
Clean core levels
SAP's clean core guidance now grades extensions by level rather than calling them simply clean or not. Level A uses only released APIs and extension points; it is the target for new work and the only option in Public Edition. Lower levels use SAP's classic APIs or internal objects, with rising upgrade risk, and the lowest level covers modifications and similar techniques SAP advises against. Definitions are refined over time, so check SAP's current documentation before classifying an extension. For a business audience, the point is simple: the further an extension is from level A, the more likely it breaks at an upgrade, and the more testing it costs every time.
Public Edition customers sometimes assume clean core is an IT concern that does not touch them, because the platform enforces it. It does touch them: key user extensions such as custom fields and custom logic are still customer code and configuration. SAP keeps the extension point stable, but the logic inside it (a validation rule, a calculation, a field on a form) is for the customer to test. Stable platform, customer-owned behavior.
What business users should ask
- Is there a standard way? Fit-to-standard first, configuration second, extension last.
- If we extend, can it be key user or released-API based?
- Who owns the extension after go-live, and who tests it at every upgrade?
- What happens to the process if the extension fails after an upgrade?
What would you do?
Contoso wants a check that stops sales orders when a fleet customer's contract has expired. A developer proposes a classic user exit in the sales order program, "because it is quickest". What should the process owner ask for?
- Key user, developer (ABAP Cloud) and side-by-side extensibility exist in every edition.
- Classic ABAP extensions and modifications exist only in Private Edition and on-premise.
- Clean core levels grade extensions from released-API based (A) to modifications (lowest).
- Every extension below level A adds regression testing at every upgrade.
Check your understanding · not graded
Lesson check
1. Which extension style is not available in Public Edition?
2. What characterizes a clean core level A extension?
3. Why do classic extensions increase upgrade testing?
4. A rarely used classic report breaks easily. What is the best treatment?