ABAP Cloud Part 5: On-Stack Developer Extension vs BTP Side-by-Side

📌 KEY POINTS
✅ On-stack: logic runs inside S/4HANA — best for tight coupling to SAP data and transactions.
✅ Side-by-side: separate app on BTP — best for decoupled, independent or cross-system scenarios.
✅ Both follow clean core: only released local APIs (on-stack) or released remote APIs/events (side-by-side).
⚠️ Side-by-side cannot join SAP data in the same transaction — plan for eventual consistency.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 listed the extensibility options. This part helps you decide between the two developer options.

━━━━━━━━━━━━━━━━━━━━
▶ 1. ON-STACK DEVELOPER EXTENSIBILITY
ABAP Cloud code in the S/4HANA system itself.
Strengths:

• Direct, fast access to SAP data via released CDS views (joins, analytics in one query).
• Same transaction as SAP processes: validations in released BAdIs, EML on released SAP BOs in the same LUW.
• No additional runtime, no data replication.

Limits:

• Runs on the S/4HANA system's resources and lifecycle (upgrades, downtime).
• Tied to one S/4HANA system.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SIDE-BY-SIDE ON BTP
A separate application (SAP BTP ABAP environment with RAP, or CAP with Node.js/Java) that talks to S/4HANA through released remote APIs (OData, SOAP) and business events.
Strengths:

• Independent lifecycle and scaling; can be updated without touching S/4HANA.
• Can combine several backends (S/4HANA, SuccessFactors, non-SAP).
• Suitable for external users, partners, heavy workloads.

Limits:

• Network latency and API limits; no shared transaction — changes in both systems need compensation or eventual consistency.
• Data must be read via APIs or replicated.
• Additional runtime cost and operations.

━━━━━━━━━━━━━━━━━━━━
▶ 3. DECISION CRITERIA
Choose ON-STACK when:

• the logic belongs to an S/4HANA business transaction (checks, derivations, follow-up postings);
• you need joins with large SAP data volumes or real-time analytics;
• low latency and transactional consistency matter.

Choose SIDE-BY-SIDE when:

• the app has its own data and lifecycle (e.g. supplier portal, mobile field app);
• several systems are involved;
• external users or high, variable load are expected;
• you want to isolate innovation from the ERP release cycle.

━━━━━━━━━━━━━━━━━━━━
▶ 4. HYBRID
Common pattern: on-stack for checks and events in S/4HANA; side-by-side app for the user experience, reacting to events and calling released APIs.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
Use the decision table in the code example for each requirement; document the choice in an architecture decision record.

✅ CHECKPOINT: you can justify where an extension should run.

A company wanted a supplier self-service portal and, at the same time, stricter checks when buyers create purchase requisitions. The first plan put everything on-stack, including external supplier access.
The architecture review split it: the supplier portal went side-by-side on BTP (external users, independent releases, scaling during onboarding campaigns), consuming released APIs and events; the purchase requisition checks went on-stack as a released BAdI implementation because they had to reject the save in the same transaction. Both parts stayed clean core.

• Building side-by-side apps that need the same transaction as SAP postings.
• Replicating large SAP data sets to BTP just to join them.
• Putting external-user portals on-stack.
• Ignoring API limits and latency in side-by-side designs.
• Assuming side-by-side is automatically "cleaner" than on-stack ABAP Cloud.

• Decide per requirement with explicit criteria.
• Use on-stack for transactional checks and data-heavy logic.
• Use side-by-side for independent apps, multi-system and external users.
• Use events to decouple; design compensation for cross-system changes.
• Record decisions in architecture decision records.

Questions: "When do you choose on-stack vs side-by-side?", "What are the consistency implications of side-by-side?"
Strong answer: on-stack ABAP Cloud when logic belongs to SAP transactions, needs joins on SAP data or low latency; side-by-side on BTP for own lifecycle, multiple backends, external users and independent scaling; side-by-side uses released remote APIs and events, has no shared LUW and needs eventual consistency or compensation; hybrids are common. Both follow clean core.