Integration Patterns and Data Synchronization for Side-by-Side Extensions

Explanation

A side-by-side extension is only as valuable as its integration with the core SAP system. Once a team decides to build outside the core (for example on SAP BTP using CAP, or a Java/Node application calling S/4HANA APIs), the next critical decision is how data and events flow between the extension and the core, and how consistency is maintained when the two systems are not transactionally coupled. There are three broad integration styles used in practice. First, synchronous request-response, typically via OData or REST APIs exposed by S/4HANA (on-premise via SAP Gateway/communication scenarios, or S/4HANA Cloud via released APIs in the SAP API Business Hub). This suits read-heavy scenarios or short-lived write operations where the extension needs an immediate confirmed result, such as checking stock availability before confirming an order in a custom portal. Synchronous calls are simple to reason about but couple availability: if the core system is slow or down, the extension degrades immediately, so timeout and circuit-breaker patterns become mandatory in production. Second, asynchronous event-driven integration, using SAP Event Mesh, or in older on-premise landscapes IDocs/queues via SAP Process Integration or Process Orchestration. Events such as 'sales order created' or 'material master changed' are published by the core and consumed by the extension, which then updates its own local data or triggers a workflow. This decouples availability - the extension can process events when it is ready - but introduces eventual consistency: there will be a window where the extension's view of the data is stale relative to the core. Architects must document acceptable staleness with business stakeholders, because ignoring it leads to reconciliation disputes later. Third, batch/bulk data replication, useful when the extension needs a large local dataset for performance reasons (for example an analytics or machine-learning side-by-side application that cannot afford to call the core system per record). This can use SAP BTP's data integration tooling or file-based/API-based extraction jobs. It carries the highest latency for freshness but the lowest coupling and best local read performance. Data synchronization design must also decide the system of record. In almost all side-by-side patterns, the SAP core remains the system of record for master and transactional business data; the extension holds only the data it needs to operate, often enriched with extension-specific attributes (for example a customer risk score computed by the extension). Storing a shadow copy of core data in the extension database requires a clear synchronization contract: what triggers a refresh, how conflicts are resolved if the extension also writes back to the core, and how orphaned or deleted core records are handled in the extension's copy. Error handling is a frequent gap in early designs. Synchronous integration needs retry logic with backoff for transient failures and clear error surfacing to the end user rather than silent failure. Asynchronous integration needs dead-letter handling for events that cannot be processed, plus monitoring to detect a stalled queue before business impact grows. Idempotency is essential: if an event or API call is retried after a network timeout, processing it twice must not duplicate business data, which usually means designing extension-side operations around natural business keys and upsert semantics rather than blind inserts. On ECC and S/4HANA on-premise, integration commonly still relies on IDocs, BAPIs, or RFC-enabled function modules alongside newer OData services, and the middleware layer (PI/PO or an equivalent) plays a significant mediating role. On S/4HANA Cloud Public Edition, the released, stable APIs in the SAP API Business Hub are the primary sanctioned integration surface, since direct table or custom RFC access is not available, which pushes teams naturally toward the API/event patterns described above. This constraint is generally beneficial for maintainability even when technically restrictive.

Code example

// Example: idempotent event consumer pattern (pseudocode, Node.js/CAP style)// Consumes a 'BusinessPartner.Changed' event from SAP Event Mesh// and upserts a local read model in the side-by-side extension. async function onBusinessPartnerChanged(event) {  const { businessPartnerID, changeTimestamp, payload } = event.data;   // Idempotency guard: skip if we already applied an equal-or-newer change  const existing = await db.read(LocalBusinessPartner)    .where({ ID: businessPartnerID });   if (existing && existing.lastSyncedAt >= changeTimestamp) {    log.info(`Skipping stale/duplicate event for ${businessPartnerID}`);    return;  }   // Upsert, not blind insert, to avoid duplicates on retry  await db.upsert(LocalBusinessPartner).entries({    ID: businessPartnerID,    name: payload.name,    riskScore: computeRiskScore(payload), // extension-specific enrichment    lastSyncedAt: changeTimestamp  });} // Dead-letter handling: after N failed retries, route to a review queue// instead of silently dropping the event, so support staff can investigate.

Real project scenario

A retail customer built a side-by-side credit-risk scoring application on SAP BTP that needed near-real-time visibility of sales order values against customer credit exposure. The initial design called the S/4HANA on-premise OData API synchronously on every order line entry in a custom UI, which worked in testing but caused noticeable UI lag during peak season when the core system was under heavy batch load. The team redesigned the flow to subscribe to sales order change events, maintain a local aggregated exposure table in the extension, and only fall back to a synchronous API call for the final credit check at order submission. This reduced average response time significantly and made the extension resilient to short core-system slowdowns, at the cost of documenting a few-minutes staleness window for the exposure dashboard, which business stakeholders accepted after review.

Common mistakes

• Choosing synchronous calls for every interaction without evaluating latency and coupling impact under peak load. • Treating the extension's local copy of core data as a second system of record, leading to write conflicts. • Failing to design idempotent event handlers, causing duplicated records after network retries. • No dead-letter or monitoring strategy for failed asynchronous events, resulting in silent data drift. • Ignoring the eventual-consistency window in user-facing screens, confusing end users when data appears stale. • Assuming the same integration APIs and tooling used on ECC/on-premise are available unchanged on S/4HANA Cloud Public Edition.

Best practices

• Match integration style (sync, async event, batch) to the actual latency and consistency needs of the specific use case, not a blanket standard. • Keep the SAP core system as the authoritative system of record; store only what the extension needs locally. • Design all write operations to be idempotent using natural business keys and upsert semantics. • Implement dead-letter queues and alerting for failed event processing so issues surface before business impact. • Document and socialize any eventual-consistency windows with business stakeholders before go-live. • Prefer officially released APIs (SAP API Business Hub) over undocumented interfaces, especially for S/4HANA Cloud targets.

Interview angle

Interviewers commonly probe whether a candidate understands the trade-off between synchronous and event-driven integration and can justify a choice with concrete NFRs (latency, availability, consistency tolerance) rather than defaulting to 'call the API.' Be ready to discuss idempotency, dead-letter handling, and how you would explain an eventual-consistency window to a business stakeholder.