SAP Clean Core Distributed Transactions & Sagas Pattern Guide

1. The Problem with Distributed Transactions in Cloud Architectures

In legacy on-premise monoliths, transactions relied on database-level ACID guarantees and the classic ABAP Logical Unit of Work (COMMIT WORK / ROLLBACK WORK). In a modern Clean Core architecture with side-by-side BTP microservices and external SaaS (Salesforce, Stripe, Coupa), traditional distributed two-phase commits (2PC / XA) are anti-patterns: they introduce tight coupling, hold database locks across high-latency internet connections, and create catastrophic single points of failure.

2. Saga Coordination: Orchestration vs Choreography

There are two primary styles of coordinating Sagas in SAP landscapes:

• Orchestrated Saga (Recommended for Complex Business Workflows): A central service on SAP BTP (e.g. CAP state machine or SAP Build Process Automation) tells each participant what local transaction to execute and triggers compensating actions if any step fails.
• Choreographed Saga (Best for Lightweight Event Streams): Each microservice publishes CloudEvents via SAP Advanced Event Mesh (AEM); subsequent services listen, perform work, and emit follow-up events or compensation triggers without central coordination.

3. The Anatomy of Compensating Transactions

Because a step in a Saga commits locally immediately, rolling back requires executing a compensating action that logically undoes the side effects of previous steps:

// Pseudocode of backward recovery execution
try {
  const order = await s4hana.createSalesOrder(data);
  const payment = await stripe.chargeCustomer(data.amount);
} catch (error) {
  // External step failed -> Compensate S/4HANA order
  await s4hana.compensateAndCancelSalesOrder(order.ID, {
    reason: 'Payment processor authorization rejected'
  });
}

4. Implementing the Transactional Outbox Pattern

To avoid race conditions where an S/4HANA transaction commits but network failure prevents publishing the CloudEvent to SAP Event Mesh, implement the Transactional Outbox pattern. The local business record and the outbox event record are saved in the same local database commit. A background daemon then guarantees reliable at-least-once delivery.

5. Interactive Tool Companion

Use our free web utility to generate complete BTP Saga orchestrators, idempotent RAP ABAP compensation actions, and transactional outbox schemas:

→ Open SAP Clean Core Distributed Sagas Architect (Tool #70)