Architect / Cross-trackAdvanced

SAP BTP Side-by-Side Extension for Clean Core (Part 8)

Key takeaway

Choose side-by-side BTP extension when the capability benefits from an independent lifecycle and loose coupling, integrating through released APIs or events rather than recreating tight save-time dependencies outside S/4HANA.

Explanation

Side-by-side extension moves custom capabilities out of the S/4HANA core onto SAP BTP or another approved cloud runtime. It is a strong fit for portals, workflow, analytics, AI enrichment, partner applications and services that can operate through released APIs or business events.

The key decision is coupling. A capability that must synchronously block a document save in milliseconds may be better implemented with a released in-core BAdI or ABAP Cloud extension. Moving that check to BTP can add network latency and make core transaction availability depend on an external service.

Conversely, processes that can react asynchronously or tolerate independent scaling benefit from side-by-side architecture. Events can decouple producers and consumers, while released OData, SOAP or other APIs provide controlled reads and commands.

Side-by-side is not automatically clean core. A BTP app that calls unreleased RFCs or reads internal SAP tables through a custom tunnel still creates upgrade-sensitive dependency. The cleanliness comes from released contracts and clear ownership.

Design monitoring, authentication, retry, idempotency and data residency alongside the functional architecture.

Code example

ABAP Code

"Good side-by-side candidates"- partner/customer portal"- external data enrichment"- AI scoring/recommendation"- workflow outside core save"- analytics/dashboard "Prefer released APIs/events."Keep synchronous save-time rules in-core when coupling requires it.

Real project scenario

A supplier-risk dashboard combined S/4 supplier data with an external risk provider. A BTP service consumed released APIs and external feeds without adding logic to the S/4 purchasing transaction.

Common mistakes

Moving tightly coupled save logic out of core unnecessarily.
Calling unreleased backend interfaces from BTP.
Ignoring retry and idempotency.
Creating synchronous dependency on a remote service for every item.
Having no end-to-end monitoring ownership.

Best practices

Choose side-by-side for loose coupling and independent lifecycle.
Keep critical save-time logic close to the transaction when needed.
Use released APIs and events.
Design observability and retry from day one.
Assign clear product and integration ownership.

Interview angle

Explain when side-by-side BTP is preferable to in-core extensibility and why released interfaces are central to clean-core architecture.

Practice this lesson

Quick check

1. In the lesson "Side-by-Side Extension on BTP", consider this project situation: A supplier-risk dashboard combined S/4 supplier data with an external risk provider. Which statement is correct?

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

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

Interview questions

1. How do you decide between in-app extension and side-by-side extension?

Answer it in your own words first, then compare.

2. Using this SAP project situation — A supplier-risk dashboard combined S/4 supplier data with an external risk provider — explain Side-by-Side Extension on BTP. 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.

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.