Side-by-Side Extension on BTP

Explanation

Side-by-side extension means building custom applications or services outside the S/4HANA core, commonly on SAP BTP, and integrating using released APIs, events or integration services. This approach is suitable when the process is loosely coupled, uses external systems, needs independent lifecycle, or should not increase upgrade risk inside the core. It is not suitable for every scenario. If logic must run synchronously inside a save process, an in-core released BAdI may be better. Clean Core architecture requires understanding coupling and timing.

Code example

* Side-by-side decision guide:** Good candidates:* - Dashboard or analytical app* - External data enrichment* - Workflow or approval outside transaction save* - AI scoring or recommendation service* - Partner/customer portal** Poor candidates:* - Logic that must block SAP document save immediately* - High-volume synchronous item-level validation inside pricing** Integration principle:* Use released APIs/events, not direct database access.

Real project scenario

A supplier risk dashboard consumed S/4HANA supplier data and external risk scores. Instead of enhancing the core transaction, the team built a BTP side-by-side app using released APIs.

Common mistakes

- Moving tightly coupled save logic outside core unnecessarily. - Building BTP app with unreleased backend dependencies. - Ignoring latency and consistency. - Not defining ownership and monitoring.

Best practices

- Use released APIs/events. - Choose side-by-side for loose coupling. - Consider latency and transaction timing. - Define monitoring and ownership. - Keep core clean and stable.

Interview angle

A strong answer should explain coupling: loosely coupled extensions fit side-by-side; save-time core validations may need released in-core extensibility.