Architect / Cross-trackIntermediate

SAP S/4HANA Clean Core: On-Stack vs Side-by-Side Extensions (Part 2)

Key takeaway

Use a consistent Clean Core decision sequence—standard, key-user extensibility, released on-stack extension, released API or side-by-side BTP—before accepting tightly coupled custom code as a governed exception.

Explanation

Clean Core decisions should begin with the business requirement, not with a preferred technology. The first question is whether standard S/4HANA configuration or process design already solves the need. If not, evaluate the least coupled supported extension option that can still meet the required transaction timing and user experience.

Key-user extensibility suits bounded field, UI and logic extensions where the application exposes supported tools. Developer extensibility with ABAP Cloud and released BAdIs or APIs is appropriate when custom ABAP must execute on stack but should remain within a stable release contract. Side-by-side BTP extensions are valuable when the capability needs an independent lifecycle, broader technology stack or asynchronous integration boundary.

Timing matters. A validation that must block sales-order save may require an on-stack released BAdI; moving it to a remote BTP application simply to look cleaner can make the process less reliable.

If no supported option satisfies the requirement, record the exception with owner, rationale, risk, expected lifetime and review date. Clean Core is a governance discipline, not a ban on every tightly coupled extension.

Revisit decisions after upgrades because SAP may release new APIs or extensibility options.

Ask for measurable requirements before choosing a platform

Define when the result is needed, what happens if a dependency is unavailable, which system owns the data, and who supports the extension. Check the required released interface in the customer's exact edition and release.

For synchronous validation, identify whether the supported extension can participate in the business transaction. For an asynchronous design, define acceptable delay, duplicate handling, failed-message recovery and monitoring ownership. Independence of deployment does not remove these responsibilities.

Record the chosen option and one rejected alternative with concrete reasons. If no supported mechanism satisfies the requirement, raise the gap through governance rather than labelling an arbitrary wrapper or remote call clean core. Reassess the decision when supported product capabilities change.

References and further reading
SAP ABAP Cloud extensibility overview: https://help.sap.com/docs/abap-cloud/abap-cloud/extensibility?locale=en-US

Continue learning
Classifying Custom Code for Clean Core: https://erpclimb.com/lessons/classifying-custom-code-for-clean-core
Released APIs and Release Contracts in ABAP Cloud: https://erpclimb.com/lessons/rap-abap-cloud-released-apis-release-contracts

Code example

ABAP Code

"Decision sequence"1. Standard configuration/process?"2. Key-user extensibility?"3. Released ABAP Cloud API or BAdI?"4. Side-by-side BTP via released API/event?"5. Governed exception with owner and review date

Real project scenario

Illustrative comparison: a rule must reject an invalid order before save, while a dashboard can update after the order is committed. Evaluate a supported local extension point for the first requirement. For the dashboard, evaluate an asynchronous integration and separate application if its freshness target permits it. These are design candidates, not promises that a particular BAdI or event exists in every S/4HANA edition.

Common mistakes

Jumping to implicit enhancement first.
Using BTP for logic that must execute synchronously inside the transaction.
Ignoring standard configuration.
Treating technically visible APIs as released contracts.
Accepting exceptions without ownership or review.

Best practices

Start from business timing and semantics.
Prefer the least coupled supported option.
Verify released status.
Record exceptions formally.
Reassess old exceptions as SAP capabilities evolve.

Interview angle

Explain Clean Core as a decision framework and give an example where on-stack extension is better than side-by-side BTP.

Practice this lesson

Quick check

1. Scenario — A company wanted a save-time compliance validation. Which response best addresses the design or operating risk in Clean Core Extension Decision Framework?

2. When is side-by-side extension on BTP usually a good fit?

3. What is the main goal of Clean Core?

Interview questions

1. Using this SAP project situation — A sales-order custom field was added through key-user extensibility, while an external partner-risk scoring application was built on BTP because it needed third-party data and independent scaling — explain Clean Core and Extensibility Types. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

2. A business requirement can be solved by configuration or a custom enhancement. What should you choose in Clean Core thinking?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.