Ein Transformation Flow ist ein Baustein in SAP Datasphere (der SAP-Datenplattform in der Cloud), der bereits geladene Tabellen innerhalb der Plattform umbaut und das Ergebnis in eine Zieltabelle schreibt. Er übernimmt den Umform-Schritt eines ELT-Ablaufs (Extract-Load-Transform: erst laden, dann in der Zielplattform umformen) und verarbeitet dabei nur die Datensätze, die sich seit dem letzten Lauf geändert haben (Delta-Staging).
Was ist ein Transformation Flow?
Ein Transformation Flow ist ein konkretes Datasphere-Objekt, das im [Data Builder](/insights/glossar/data-builder/) (der grafischen Modellierungs-Oberfläche von Datasphere) angelegt wird. Aufgabe ist die Umformung: eine oder mehrere Local Tables (Tabellen, die physisch in Datasphere liegen) im selben Arbeitsbereich werden über typische Datenbank-Operationen wie Verknüpfen (Join), Filtern, Spaltenauswahl, Verdichten und Vereinigen zu einer Zieltabelle zusammengeführt. Reicht die grafische Modellierung nicht, lässt sich die Logik alternativ als SQL-Skript oder Python-Skript hinterlegen. Neue Daten von außen holt der Flow nicht. Seine Quellen sind Objekte, die bereits in Datasphere vorhanden sind.
Zentrales Konstruktionsmerkmal ist das Delta-Staging. Jede Quell-Local-Table trägt einen Änderungs-Log-Bereich, den der Transformation Flow beim nächsten Lauf ausliest. Verarbeitet werden nur die Datensätze, die seit dem letzten Lauf hinzugekommen, geändert oder gelöscht wurden. Das reduziert Laufzeit und Verrechnungsverbrauch gegenüber Voll-Verarbeitungen und schließt an eine typische ELT-Kette an, in der ein [Replication Flow](/insights/glossar/replication-flow/) die Änderungen der Quellsysteme per Change Data Capture in die Datasphere-Local-Tables gebracht hat.
Für die Ausführung stehen zwei Run-Modes zur Verfügung. Der Performance-Optimized-Modus zieht mehr HANA-Cloud-Ressourcen und liefert kürzere Laufzeiten; der Memory-Optimized-Modus arbeitet mit engerem Speicherbudget und ist für lange, breite Läufe gedacht, die andernfalls die Zuteilung sprengen würden. Die Trigger-Logik ist außerhalb des Flows selbst geregelt: eine [Task Chain](/insights/glossar/task-chain/) reiht Transformation Flows nach den vorgelagerten Replication Flows ein, ein Zeitplan startet zyklisch, ein manueller Lauf im Data Builder deckt Ad-hoc-Fälle ab.
Der Objekttyp existiert, weil SAP mit Datasphere den älteren [Data Flow](/insights/glossar/data-flow/) durch ein ELT-Muster mit Delta-Verarbeitung ablösen wollte. Der Transformation Flow ist im aktuellen Datasphere-Katalog als First Choice für Transformationen positioniert; der Data Flow bleibt als Fallback für Sonderlogik ohne SQL-Äquivalent bestehen.
Abgrenzung zu Replication Flow, Data Flow, Remote Tables und Analytic Model
Die häufigsten Verwechslungen entstehen zwischen den drei Flow-Objekttypen im Data Builder und gegenüber virtualisierten Objekten sowie der Semantik-Schicht darüber.
| Begriff | Kernunterschied zum Transformation Flow |
|---|---|
| Replication Flow | Extract-and-Load-Objekt: kopiert Daten aus SAP- und Nicht-SAP-Quellen per Change Data Capture in Datasphere-Local-Tables. Der Transformation Flow setzt auf diesen Local Tables auf und transformiert, extrahiert aber selbst nicht. |
| Data Flow | Legacy-Objekttyp ohne Delta-Verarbeitung, läuft in einem Kubernetes-Pod mit rund 20 Sekunden Init-Zeit. Der Transformation Flow arbeitet Delta-basiert und in-HANA-Cloud, ist damit für hochfrequente Läufe und größere Volumen ausgelegt. |
| Remote Tables | Virtualisierte Tabellen, die per Föderation ohne physische Kopie auf ein Quellsystem zugreifen. Der Transformation Flow kann sie als Quelle einbinden, transformiert aber persistent in eine Local Table statt zur Query-Zeit. |
| Analytic Model | Konsumfertiges semantisches Modell im Business Builder mit Kennzahlen, Dimensionen und Perspectives. Der Transformation Flow liefert die physisch vorbereitete Zieltabelle, das Analytic Model definiert die Semantik darauf. |
| Open SQL Procedure | HANA-SQLScript im Open-SQL-Schema, set-based Pushdown auf Datenbank-Ebene ohne Datasphere-Objektmodell. Der Transformation Flow bietet die gleiche Ausführungscharakteristik im gekapselten Datasphere-Artefakt mit Delta-Staging und Katalog-Sichtbarkeit. |
Die Wahl zwischen den Flow-Typen folgt der Rolle im Datenweg: Replication Flow für den Weg in Datasphere hinein, Transformation Flow für die Verarbeitung innerhalb, Data Flow nur für Sonderfälle, für die weder SQL noch das Delta-Staging-Modell passen.
Beispiel: Verkaufskennzahlen aus VBAK und VBAP zu einem Analytic Model
Ein Datasphere-Space „Sales" enthält zwei Local Tables VBAK_Local und VBAP_Local, die per Replication Flow aus einem S/4HANA-System kopiert wurden und über Change Data Capture kontinuierlich synchronisiert bleiben. Ziel ist eine analytische Tabelle Sales_Header_Aggregated, die Auftragsposition auf Kopfzeile aggregiert und einige Kennzahlen ableitet (Nettoumsatz je Auftrag, Anzahl Positionen, größter Positionswert).
Im Data Builder wird ein Transformation Flow angelegt. Als Quellen dienen die beiden Local Tables, verbunden über einen Join auf der Belegnummer. Ein Aggregations-Operator gruppiert nach Auftragskopf und berechnet die Kennzahlen, eine Projection blendet nicht benötigte Spalten aus. Als Ziel dient eine neue Local Table Sales_Header_Aggregated. Der Run-Mode wird auf Performance-Optimized gesetzt, weil das nächtliche Zeitfenster knapp ist.
Die Ausführung ist Teil einer Task Chain: Zuerst laufen die Replication Flows, die neue Auftragspositionen aus S/4HANA nachziehen, danach der Transformation Flow, der ausschließlich die geänderten Belegnummern über das Delta-Staging verarbeitet. Auf Sales_Header_Aggregated sitzt ein Analytic Model, das die Kennzahlen für SAP Analytics Cloud oder eine über BDC Connect angebundene Databricks-Instanz freigibt.
Transformation Flow im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
Dach-Produkt, in dem Datasphere-Flows als Transformations-Baustein sitzen
SAP DataspherePlattform-Kontext, in dem der Transformation Flow als Data-Integration-Objekt lebt
Replication Flowvorgelagerter Extract-and-Load-Baustein, dessen Local Tables der Transformation Flow als Quelle nutzt
Data FlowLegacy-Objekttyp ohne Delta-Verarbeitung, den der Transformation Flow als First Choice ablöst
Remote Tablesföderierte Gegenseite; Transformation Flows können sie als Quelle einbinden, transformieren aber persistent
Data BuilderModellierungswerkzeug, in dem Transformation Flows als Objekttyp erscheinen
Analytic Modelssemantisches Modell auf den Ziel-Tabellen, die ein Transformation Flow befüllt
Task ChainOrchestrierung, die Replication Flow und Transformation Flow in Reihe schaltet
Change Data CaptureVerfahren, mit dem die Quellen des Transformation Flows aktuell gehalten werden
ELTVerarbeitungsmuster, dessen T-Schritt ein Transformation Flow innerhalb Datasphere übernimmt