Replication Flows
As of 2026-10-10
Replication Flow = canonical CDC pipeline S/4 → DSP. Throughput ~10 GB/h per partition. Senior pattern: partition by business key + date, 16-32 partitions for large facts, schema monitoring on every source. Top failure: wrong partition count. Memorize 5 failure modes (schema drift, under-sized partitions, delta backlog, PII leak, Cloud Connector outage). Pair with M003 + M004 for full foundation skill.
What you will learn
- Work through a realistic scenario: DAX-40 industrial group, S/4HANA on-prem 800M-row BSEG, 12-hour weekend window for initial load, CDC steady-state thereafter.
- Recognize and avoid the anti-pattern: 1 partition for an 800M-row fact — Initial load 80 hours, miss window.
- Apply the module's core decision: CDC vs full reload — choose CDC for any source > 1M rows or change rate > 1 %/day, not Full reload on large tables (window pressure, cost).
- Track mastery with the KPI: Initial load runtime (target: < planned window with 20 % buffer; red flag: > window = under-partitioned).
Replication Flow is the canonical change-data-capture (CDC) pipeline that moves data from S/4HANA and other SAP sources into SAP Datasphere. Roughly 80% of foundation-track engagements touch Replication Flow at some point, which makes it, in practical terms, the single highest-leverage technical skill in the Foundations & Core track: get this wrong and every downstream model, every semantic layer, every SAC story is built on data that arrived late, incomplete, or silently broken.
What Replication Flow actually does
Replication Flow moves data in two phases. The initial load takes a full snapshot of the source table or view and lands it in a Datasphere local table. Once the initial load completes, the flow switches to delta mode, streaming only the changes — inserts, updates, deletes — that have occurred since the last successful load. This two-phase pattern is standard for any CDC tool, but the SAP-specific value is in how the delta is captured: Replication Flow does not poll the source table and diff it against a prior snapshot. Instead, it rides on the source's native change-tracking mechanism, which means the change events it captures are already correct at the business-object level, not reconstructed after the fact.
Prerequisites
- Review core concepts first: C005, C008, C006
Outcomes
- Work through a realistic scenario: DAX-40 industrial group, S/4HANA on-prem 800M-row BSEG, 12-hour weekend window for initial load, CDC steady-state thereafter.
- Recognize and avoid the anti-pattern: 1 partition for an 800M-row fact — Initial load 80 hours, miss window.
- Apply the module's core decision: CDC vs full reload — choose CDC for any source > 1M rows or change rate > 1 %/day, not Full reload on large tables (window pressure, cost).
- Track mastery with the KPI: Initial load runtime (target: < planned window with 20 % buffer; red flag: > window = under-partitioned).
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.