Lesson 2 of 5
Placing extensions: on-stack or side-by-side
10 min
Listen to this lesson
Every extension needs a home. SAP describes three broad options. Key user extensibility is on-stack and low-code: custom fields, custom logic and custom business objects built by business experts in Fiori apps. Developer extensibility is on-stack and pro-code: ABAP Cloud development inside SAP S/4HANA when tighter coupling with the core is needed. Side-by-side extensibility runs outside the core on SAP BTP, using public remote APIs and events to reach core data, with access to the wider range of BTP services. All three can be clean core level A when they use released interfaces.
What decides placement
| Question | Points on-stack | Points side-by-side |
|---|---|---|
| Must it act inside an SAP transaction, for example validate a document while it is saved? | Yes: only on-stack logic runs in that transaction | No |
| Does it need data from several systems, or BTP services such as AI or workflow? | No | Yes |
| Who uses it? | Existing SAP users in their normal apps | A different user group, such as customers or field staff |
| How often does it change? | With the ERP release rhythm | On its own, faster schedule |
| How much data does it read, how often? | Large volumes, row by row, in real time | Moderate volumes through APIs or events |
| Who builds it? | ABAP developers or key users | Developers with cloud skills (CAP, Java, Node.js, or the ABAP environment) |
SAP Learning puts the side-by-side case simply: an application that needs SAP S/4HANA data but not its runtime environment. It reads core data through remote public released APIs and may combine it with other sources, store it locally or use other BTP services. Typical uses are apps that need AI or other BTP services, apps that integrate several on-premise and cloud systems, and partner SaaS solutions. Because the extension runs on its own lifecycle, the core and the extension can be updated independently.
Contoso's extension portfolio
| Need | Placement | Why |
|---|---|---|
| Block sales orders when a core deposit is unpaid | On-stack: custom logic in a released sales document extension point | Must stop the save inside the transaction |
| Purchase orders over $25,000 need approval | Standard: flexible workflow configuration, no extension | The standard covers it |
| Great Lakes Fleet Services staff check order status | Side-by-side: fleet order status app on Cloud Foundry, launched from SAP Build Work Zone | External users, own release rhythm, read-only API access |
| Send an advance shipping notice when a delivery is posted | Side-by-side integration: Cloud Integration flow triggered by a business event | Partner-facing message mapping and monitoring belong in the integration layer |
| Core return agreements (custom table from ECC) | On-stack, being moved to released views | Tightly bound to sales documents; data stays in the core |
Where Contoso places each extension, and why.
Events instead of polling
Side-by-side does not have to mean "call the API every five minutes". SAP's event-driven reference architecture describes SAP applications publishing business events, with extensions on BTP consuming them through SAP Cloud Application Event Hub or, for broader landscapes, the event broker offerings of SAP Integration Suite (the Event Mesh capability for starter or small-volume scenarios and advanced event mesh for large, distributed ones). Business events supported by SAP are listed in the SAP Business Accelerator Hub. Custom or derived events can be built with the ABAP RESTful Application Programming Model. Contoso's ASN flow uses this pattern: a posted outbound delivery raises an event, and the integration flow builds and sends the ASN.
- Must the logic run inside an SAP transaction or change the document being saved?Yes → on-stack (key user custom logic first, ABAP Cloud if needed) · No → next question
- Is it a simple field, rule or form a business expert can build?Yes → key user extensibility · No → next question
- Does it serve other users, combine systems or need BTP services?Yes → side-by-side on BTP with released APIs or events · No → developer extensibility on-stack
- Does it react to something that happened in SAP S/4HANA?Yes → consume a business event rather than polling · No → call released APIs on demand
Placement decides the lifecycle
Placement also decides how an extension lives after go-live. On-stack extensions travel with SAP S/4HANA transports and are tested in every ERP release and stack. Side-by-side extensions have their own pipeline, release rhythm and runtime updates on SAP BTP, and they meet SAP S/4HANA only at the APIs and events they use. That independence is a strength, because the fleet order status app can ship a fix on a Tuesday without an ERP transport, but it creates a second change stream that the release calendar must track. Contoso ties both streams to the same release in SAP Cloud ALM whenever a change spans them.
What would you do?
Maria wants a warning when a sales order's requested delivery date falls on a Detroit plant shutdown day. A developer proposes a side-by-side app that checks new orders every ten minutes. What placement fits best?
- Three options: key user (on-stack, low-code), developer (on-stack, ABAP Cloud) and side-by-side (BTP).
- Logic that must act inside a transaction belongs on-stack; other users, other systems or BTP services point side-by-side.
- Prefer business events over polling for side-by-side reactions.
- Clean core levels apply to the interfaces used, wherever the extension runs.
Check your understanding · not graded
Lesson check
1. Which extension must run on-stack?
2. How does SAP Learning characterize a side-by-side extension?
3. Which SAP BTP service gives access to business events from SAP cloud applications?
4. A BTP app reads internal SAP tables through a custom RFC. How clean is it?