Replication Flows
Stand 2026-09-03
Replication Flow = die kanonische CDC-Pipeline S/4 → DSP. Durchsatz ~10 GB/h pro Partition. Erfahrenes Muster: Partitionierung nach Business Key + Datum, 16-32 Partitionen für große Fact-Tabellen, Schema-Monitoring auf jeder Quelle. Häufigster Fehler: falsche Partitionsanzahl. Fünf Fehlerbilder verinnerlichen (Schema Drift, unterdimensionierte Partitionen, Delta-Rückstau, PII-Leck, Ausfall des Cloud Connector). Zusammen mit M003 + M004 ergibt sich die vollständige Foundation-Kompetenz.
Was Sie lernen
- Die Kernkonzepte hinter Replication Flows verstehen
- Replication in einem typischen SAP-Analytics-Engagement anwenden
- Die 3-5 häufigsten Fehler erkennen und wissen, wie man sie vermeidet
- Diese Fähigkeit in der eigenen persönlichen Marke und im Tagessatzgespräch positionieren
Replication Flow ist die kanonische Change-Data-Capture-(CDC-)Pipeline, die Daten aus S/4HANA und anderen SAP-Quellen in SAP Datasphere überführt. Rund 80 % der Engagements im Foundation-Track berühren Replication Flow an irgendeinem Punkt, was es in der Praxis zur technischen Fähigkeit mit der höchsten Hebelwirkung im Foundations-&-Core-Track macht: Wird dies falsch gemacht, ist jedes nachgelagerte Modell, jede semantische Schicht, jede SAC-Story auf Daten aufgebaut, die verspätet, unvollständig oder stillschweigend fehlerhaft ankamen.
Was Replication Flow tatsächlich tut
Replication Flow bewegt Daten in zwei Phasen. Der Initial Load nimmt einen vollständigen Snapshot der Quelltabelle oder -view und landet ihn in einer lokalen Tabelle in Datasphere. Sobald der Initial Load abgeschlossen ist, wechselt der Flow in den Delta-Modus und streamt nur die Änderungen — Inserts, Updates, Deletes —, die seit dem letzten erfolgreichen Ladelauf aufgetreten sind. Dieses Zweiphasen-Muster ist Standard für jedes CDC-Tool, aber der SAP-spezifische Mehrwert liegt darin, wie das Delta erfasst wird: Replication Flow pollt die Quelltabelle nicht und vergleicht sie mit einem früheren Snapshot. Stattdessen reitet es auf dem nativen Change-Tracking-Mechanismus der Quelle, was bedeutet, dass die erfassten Änderungsereignisse bereits auf Business-Object-Ebene korrekt sind, nicht nachträglich rekonstruiert.
Voraussetzungen
- Zuerst die Kernkonzepte durcharbeiten: C005, C008, C006
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: DAX-40-Industriekonzern, S/4HANA on-premise mit 800-Mio.-Zeilen-BSEG, 12-Stunden-Wochenendfenster für den Initial Load, danach CDC im stationären Betrieb.
- Das Anti-Pattern erkennen und vermeiden: 1 Partition für eine 800-Mio.-Zeilen-Faktentabelle — Initial Load 80 Stunden, Zeitfenster verpasst.
- Die Kernentscheidung des Moduls anwenden: CDC vs. Full Reload — CDC wählen für jede Quelle > 1 Mio. Zeilen oder Änderungsrate > 1 %/Tag, kein Full Reload bei großen Tabellen (Zeitdruck, Kosten).
- Die Beherrschung mit dem KPI verfolgen: Initial-Load-Laufzeit (Ziel: < geplantes Zeitfenster mit 20 % Puffer; Warnsignal: > Zeitfenster = unterpartitioniert).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.