Side-by-Side Extensibility
Side-by-side extensibility is SAP's extension approach in which custom applications run outside SAP S/4HANA, usually on SAP BTP, and connect to the ERP through released remote APIs and events instead of changing its code. Side-by-side extensions are loosely coupled: they have their own runtime, lifecycle and technology stack, such as ABAP, Java or Node.js.
Quick facts
- Type
- Extensibility option (loosely coupled, off-stack)
- Layer
- SAP BTP side lane, next to the SAP S/4HANA stack
- Runs on
- SAP BTP: Cloud Foundry, Kyma or ABAP environment
- Connects through
- Released remote APIs and business events
- Typical tools
- SAP Build Code (CAP, SAPUI5, SAP Fiori elements), SAP Build Apps, SAP BTP ABAP environment
- Who works with it
- Developers, extensibility architects, integration teams
- Applies to
- SAP BTP with SAP S/4HANA in every deployment option
Layer: SAP BTPWhere it sits ▾
Layer: SAP BTP
Open the architecture map →How does side-by-side extensibility work?
A side-by-side extension is a separate application that treats SAP S/4HANA as a system it talks to, not as code it changes:
- The extension is built and deployed on SAP BTP, in the runtime and language that fit the use case: ABAP in the SAP BTP ABAP environment, or Java and Node.js, for example with CAP.
- It reads and changes SAP S/4HANA data only through released remote APIs, which SAP documents on the SAP Business Accelerator Hub.
- It can react to business events that SAP S/4HANA publishes, so that it does not have to poll for changes.
- Connectivity and trust are configured between SAP BTP and the ERP: destinations, plus SAP Cloud Connector for on-premise systems.
- The extension has its own lifecycle. It is deployed, scaled and updated independently of SAP S/4HANA releases.
Side-by-side extensibility therefore turns an extension into an integration problem with its own application, rather than a change inside the ERP.
Which kinds of side-by-side extensions are common?
SAP's extension guidance names several archetypes for side-by-side applications:
- Proxy and convenience apps that simplify or reshape access to SAP S/4HANA for a specific audience.
- Substitute apps that replace a standard step with a custom one.
- Preprocessing and postprocessing apps that prepare data before it reaches the ERP or act on what the ERP produced.
- Analytical apps that combine SAP S/4HANA data with other sources.
Typical patterns include full-stack apps for one customer, multitenant SaaS apps built by partners, hub scenarios that connect several ERP systems or cloud services, mobile apps, and automation across systems. At Alder Manufacturing, a delivery-status portal for Bright Freight drivers, who have no SAP S/4HANA user, is a natural side-by-side case. Side-by-side extensibility fits best where the extension serves new users, new channels or several systems.
What are the strengths of side-by-side extensibility?
- Clean core by architecture. The ERP is not modified, and the extension depends only on released APIs and events.
- Independent lifecycle. The extension can ship weekly while SAP S/4HANA follows its own release calendar, and SAP S/4HANA upgrades do not touch its code.
- Free choice of stack. Teams can use ABAP, Java or JavaScript and the SAP BTP services that fit, from SAP Build Apps to CAP.
- Reach beyond SAP users. External partners, suppliers and customers can use the extension without SAP S/4HANA accounts.
- Multi-system scope. One application can combine SAP S/4HANA with other SAP and non-SAP systems.
For extensions with their own audience, scaling needs or release rhythm, side-by-side extensibility is the option SAP positions on SAP BTP.
Where does side-by-side extensibility stop?
- No shared transaction. A remote call cannot change SAP data and custom data in one unit of work, so consistency must be designed with compensations or retries.
- Bounded by remote APIs. If no released API or event covers the needed operation, the extension cannot reach it cleanly; an on-stack ABAP Cloud API may have to be built first.
- More moving parts. Connectivity, identity propagation, monitoring and operations are added for every extension.
- Data volume and latency. Reading large amounts of SAP data, or making many fine-grained calls, is slower and costlier than on-stack access.
- A second lifecycle to own. Each extension needs an owner, a budget and a support model after go-live.
Side-by-side extensibility keeps the core clean by moving complexity into the landscape around it, where it still has to be managed.
When should an extension go side-by-side instead of on-stack?
SAP's extension architecture guidance gives a practical test. Characteristics that point to each option:
| Points to side-by-side on SAP BTP | Points to on-stack (key user or ABAP Cloud) |
|---|---|
| Users without SAP S/4HANA accounts | Changes SAP and custom data in one transaction |
| Own lifecycle, scaling and frequent releases | Reads high data volumes with complex joins |
| Standalone app or decoupled process step | Many round trips to SAP data |
| Custom data independent of SAP tables | Extends an SAP app's fields, logic or UI |
Many requirements need both: an on-stack ABAP Cloud service that exposes a custom remote API, and a side-by-side app that consumes it. The decision is made per requirement, and the coupling to SAP S/4HANA data is the deciding criterion.
What changes between SAP S/4HANA Cloud and on-premise?
- SAP S/4HANA Cloud Public Edition: the SAP S/4HANA Cloud Extensibility service on SAP BTP connects a registered system to a subaccount, with the api-access service plan for APIs and the messaging plan for events; for inbound connections, an HTTP destination is generated when the service instance is created.
- Private Edition and on-premise: SAP Cloud Connector and destinations link SAP BTP to the system, and released OData APIs are activated on SAP Gateway; events leave the system through the Enterprise Event Enablement component.
- All editions: for calls that run as the signed-in user, principal propagation is configured, with single sign-on through SAP Cloud Identity Services for Public Edition and through the Cloud Connector for Private Edition and on-premise.
The extension pattern is identical across editions; only the connectivity, event setup and trust configuration differ.
Side-by-side extensibility vs. key user extensibility: what is the difference?
| Side-by-side extensibility | Key user extensibility | |
|---|---|---|
| Where it runs | Outside SAP S/4HANA, usually on SAP BTP | Inside SAP S/4HANA |
| Who builds it | Developers or business technologists | Key users and functional consultants |
| Coupling | Loose: released remote APIs and events | Tight: same system, same transaction |
| Typical use | New apps, external users, multi-system logic | Fields, checks, defaults, screen changes |
| Lifecycle | Own deployment and release cycle | Transported with the SAP S/4HANA system |
Key user extensibility adapts what SAP S/4HANA already does; side-by-side extensibility builds something new next to it.
FAQ
Is side-by-side extensibility the same as SAP BTP?
No. SAP BTP is the platform; side-by-side extensibility is one way of using it, for extensions that run outside SAP S/4HANA and connect through released APIs and events. SAP BTP also hosts integration, launchpad sites, data and AI services that are not side-by-side extensions.
Does side-by-side extensibility work with SAP S/4HANA on-premise?
Yes. Extensions on SAP BTP reach on-premise and Private Edition systems through SAP Cloud Connector and destinations, using the released OData and SOAP APIs active in that system. Public Edition systems connect through the SAP S/4HANA Cloud Extensibility service instead.
Can a side-by-side extension write data into SAP S/4HANA?
Yes, through released remote APIs that support create, update or actions. The write happens in a separate call, so the extension cannot combine it with its own database changes in one transaction and must handle failures, retries and partial updates itself.
Is side-by-side always cleaner than on-stack extensibility?
Not automatically. A side-by-side extension is clean for the ERP only if it uses released APIs. If it needs transactional consistency or heavy data access, an on-stack ABAP Cloud extension is often simpler, and both approaches respect clean core when built on released objects.
Sources
- SAP Help Portal: Side-by-side extensibility (ABAP platform)
- SAP Help Portal: Extension use case patterns — on-stack vs. side-by-side (Extension Architecture Guide)
- SAP Help Portal: Extending SAP S/4HANA Cloud in the Cloud Foundry and Kyma environment (SAP BTP)
- SAP Help Portal: ABAP Cloud and the extensibility options compared
- SAP Help Portal: Create a Service Instance to Consume the SAP S/4HANA Cloud APIs (api-access plan)
- Applies to
- SAP BTP · SAP S/4HANA on-premise · SAP S/4HANA Cloud Private Edition · SAP S/4HANA Cloud Public Edition
- Last reviewed