.svg)
Der Vertrieb benötigt aktuelle Umsatzzahlen. Die IT exportiert die entsprechenden Daten aus SAP, jemand überträgt sie in eine Tabelle und daraus wird wiederum ein Bericht erstellt. Bis dieser fertig ist, sind die Zahlen schon wieder veraltet. Und irgendwo läuft längst der nächste Export.
Dabei ist das Problem nicht SAP. SAP macht seinen Job: Es führt Aufträge, pflegt Kundendaten und bucht Umsätze – zuverlässig und in Echtzeit. Das Problem liegt im weiteren Prozess. Wie kommen diese Daten aus SAP heraus und in die Systeme, mit denen das Business täglich arbeitet, sodass sie dort auch wirklich aktuell ankommen? Solange die Antwort „manueller Export, Skript, Warteschleife” lautet, bleibt Reporting ein Engpass. Entscheidungen basieren auf veralteten Daten – von gestern oder sogar von letzter Woche. Und die IT verbringt Zeit damit, Extraktionsprozesse am Laufen zu halten. Echter Mehrwert? Fehlanzeige.
Dieser Beitrag zeigt, eine Medallion-Pipeline in Microsoft Fabric diesen Engpass auflöst und welche technischen und organisatorischen Aspekte dabei eine Rolle spielen.
Zwei Wege nach Fabric – und warum sich dieser Beitrag auf einen konzentriert
Microsoft Fabric bietet grundsätzlich zwei Wege, um SAP-Daten kontinuierlich verfügbar zu machen. Dabei nutzen beide Ansätze OneLake als zentrale Datenspeicherlösung, die alle Unternehmensdaten in einer einheitlichen Umgebung zusammenführt.
Der erste Weg ist via Open Mirroring. Über eine delta-fähige SAP-Schnittstelle – beispielsweise Xtract Universal – werden inkrementelle Änderungen aus SAP automatisch in Delta-Tabellen in OneLake übernommen. SAP-Daten lassen sich so nahtlos mit anderen Unternehmensdaten kombinieren und nahezu in Echtzeit für Analysen nutzen, ohne komplexe Transformationslogik vorschalten zu müssen.
In diesem Beitrag geht es um den zweiten Weg, den sogenannten Pipeline-basierten Ansatz über eine Medallion-Architektur. Dieser Ansatz eignet sich besonders, wenn SAP-Daten nicht nur übertragen, sondern auf dem Weg dorthin strukturiert, angereichert und in auswertbare Geschäftsobjekte überführt werden sollen. In Kombination mit einer delta-fähigen SAP-Schnittstelle werden dabei nur geänderte Datensätze verarbeitet, anstatt bei jedem Lauf den gesamten Datenbestand zu bewegen. Das hält die verarbeitete Datenmenge schlank, unabhängig davon, wie groß die SAP-Tabellen dahinter sind.
Das Prinzip
Die „klassische“ Datenintegration arbeitet nach einem strikten Fahrplan: nächtliche Batches, stündliche Exporte, feste Zeitfenster. Zwischen zwei Läufen sind die Berichte bereits veraltet. Nicht weil die Technologie es nicht besser könnte, sondern weil der Prozess so aufgebaut ist.
Ein anderer Ansatz ist Change Data Capture (CDC). Statt regelmäßig den gesamten Datenbestand zu übertragen, werden hierbei ausschließlich die Datensätze weitergegeben, die sich seit dem letzten Lauf tatsächlich verändert haben, darunter neue Einträge, Aktualisierungen, Löschungen. Das reduziert nicht nur die übertragene Datenmenge erheblich, sondern schafft auch die Grundlage für etwas Entscheidendes: Datenaktualität.
Denn kombiniert mit Microsoft Fabric läuft die Pipeline nicht nach Uhr, sondern ereignisgesteuert. Das bedeutet, sie wird automatisch angestoßen, sobald neue Daten eintreffen. Ein Verkaufsauftrag, der um 14:00 Uhr in SAP angelegt wird, ist wenige Augenblicke später im Power-BI-Dashboard sichtbar. Nicht erst am nächsten Morgen.
Ein weiterer Vorteil: Da ausschließlich geänderte Datensätze verarbeitet werden, bleiben auch die Verarbeitungskosten in Microsoft Fabric überschaubar, im Gegensatz zu Ansätzen, die bei jedem Lauf den vollständigen Datenbestand bewegen.
Warum nicht einfach den nativen ADF-Konnektor nutzen?
Microsoft stellt mit dem SAP-Konnektor für Azure Data Factory (ADF) eine eigene Integrationslösung bereit. Für viele Szenarien ist das ein sinnvoller Ausgangspunkt. Wer jedoch tiefer schaut, stößt auf Einschränkungen, die in der Praxis relevant werden.
Der ADF-Konnektor für inkrementelle SAP-Extraktion basiert auf SAPs ODP-Framework (Operational Data Provisioning). SAP hat den Zugriff auf dieses Framework für Drittanbieter-Tools seit Juni 2026 verschärft. Mit der Konsequenz, dass ODP-RFC-Aufrufe blockiert werden. Für Unternehmen, die ihren inkrementellen Datenabzug auf dem nativen ADF-Konnektor aufgebaut haben, ist das ein Risiko, das mittel- bis langfristig Handlungsbedarf erzeugt.
Hinzu kommt ein weiteres strukturelles Limit: Die CDC-Fähigkeiten des ADF-Konnektors stehen in Microsoft Fabric Data Factory aktuell nicht nativ zur Verfügung – wer inkrementelle SAP-Extraktion direkt in Fabric realisieren möchte, benötigt entweder Umwege über ADF als vorgelagerte Schicht oder alternative Lösungen.
Xtract Universal setzt auf einen anderen Ansatz: Die Extraktion erfolgt direkt über SAP-seitige Function-Module, unabhängig vom ODP-RFC-Framework – und schreibt die Ergebnisse als Parquet-Dateien direkt in OneLake. Kein ODP-Risiko, keine zusätzliche ADF-Schicht, keine Abhängigkeit von Microsofts SAP-Konnektor-Roadmap.
Mehr über die ODP-Alternative erfahren
Der Weg der Daten von SAP bis Power BI
Um SAP-Daten nicht nur zu übertragen, sondern sie schrittweise in auswertbare Geschäftsinformationen zu verwandeln, folgt der Pipeline-basierte Ansatz der Medallion-Architektur. Dies ist ein bewährtes Strukturprinzip für moderne Datenpipelines in Microsoft Fabric. Die Daten durchlaufen dabei drei aufeinander aufbauende Schichten, bevor sie als fertiger Bericht im Dashboard landen. Diese Bronze-Silver-Gold-Layer-Struktur ist das Herzstück jeder Medallion-Architektur.
Bronze Layer: das unveränderte SAP-Abbild
Hier landen die SAP-Daten zuerst. Unverändert und vollständig, als exaktes Abbild der Quelltabellen. Keine Transformation, keine Interpretation. Der Bronze Layer ist der zuverlässige, stets aktuelle Spiegel des SAP-Systems und bildet die Grundlage für alle weiteren Schritte.
Silver Layer: aus Tabellen werden Geschäftsobjekte
Im Silver Layer werden aus technischen SAP-Tabellen verständliche Geschäftsentitäten: Ein Kunde ist ein Kunde, ein Verkaufsauftrag ist ein Verkaufsauftrag – bereinigt, konsolidiert und in einer Form, die das Business direkt wiedererkennt.
Gold Layer: reporting-fertige Kennzahlen
Der Gold Layer liefert die Daten genau in der Verdichtung, die das Dashboard braucht: Umsatz pro Kunde, tägliche Verkaufszahlen, Trendverläufe. Hier wird aus Rohmaterial ein fertiges Analyseergebnis.
Konfiguration statt Code: neue Tabellen per Eintrag
Eine zentrale Konfigurationsdatei steuert, welche SAP-Tabellen in die Pipeline einbezogen werden und wie die Daten strukturiert und zusammengeführt werden sollen. Diese Medallion Pipeline ist vollständig konfigurationsgetrieben: Wenn eine neue SAP-Tabelle angebunden werden soll, genügt ein einzelner Eintrag in dieser Datei. Es ist keine Anpassung der Pipeline durch die Entwicklung nötig und es ist auch keine Änderung des Codes erforderlich.
Das hat einen praktischen Effekt, der über die reine Technik hinausgeht: Die IT wandelt sich vom Flaschenhals zum Enabler. Neue Datenquellen lassen sich schnell einbinden, ohne dass jede Erweiterung ein eigenes Projekt erfordert.
Was dabei im Hintergrund passiert, läuft vollständig automatisch und aufeinander abgestimmt ab. Extraktion und Transformation greifen nahtlos ineinander. Sobald neue oder geänderte Daten aus SAP eintreffen, wird nicht nur die Extraktion angestoßen, sondern die gesamte Pipeline läuft durch, bis das Ergebnis im Dashboard verfügbar ist. Es ist kein separates Scheduling erforderlich und es ist keine manuelle Abstimmung zwischen Extraktions- und Transformationsschritt notwendig. Wer die Daten braucht, findet sie einfach vor – aktuell und ohne warten zu müssen, bis jemand den Prozess angestoßen hat.
Der unterschätzte Spezialfall: Was passiert, wenn etwas gelöscht wird?
Bei vielen Integrationsansätzen steht das Offensichtliche im Mittelpunkt: neue Datensätze übertragen und bestehende aktualisieren. Was dabei leicht übersehen wird: Was passiert, wenn in SAP etwas gelöscht wird?
Ein Beispiel: Ein Kunde wird aus dem SAP-System entfernt, weil er doppelt angelegt war, inaktiv ist oder die Datenpflege es erfordert. Ohne explizites Handling würde dieser Kunde im Dashboard einfach weiterbestehen – in Umsatzauswertungen, Kundenlisten und Trendberichten. Die Zahlen wirken stimmig, sind aber nicht mehr korrekt.
Die Pipeline berücksichtigt genau diesen Fall: Löschungen aus SAP werden erkannt und automatisch in allen nachgelagerten Schichten nachgezogen. So bleibt das Bronze Layer ein akkurates Abbild des aktuellen SAP-Stands und kein immer länger werdendes Protokoll veralteter Informationen.
Kein großes Feature, aber eines, das den Unterschied macht zwischen einem Dashboard, dem man vertraut, und einem, das man lieber noch einmal gegencheckt.
Vom Datenmodell zum Live-Dashboard
Am Ende der Pipeline steht kein Datenhaufen, sondern ein fertiger Power-BI-Report, der aus dem Gold Layer gespeist wird. Dieser stellt die Daten bereits in genau der Form bereit, die das Reporting benötigt. Die Kennzahlen sind zentral definiert: Umsatz pro Kunde, tägliche Verkaufszahlen, Periodenvergleiche. Diese Definition ist überall gültig, sodass kein Report etwas anders rechnet als ein anderer.
Was das im Alltag bedeutet, lässt sich anhand zweier konkreter Auswertungen zeigen, die Teil des Demo-Setups sind:
Top-Kunden nach Umsatz: Welche Kunden generieren den meisten Umsatz? Die Antwort ist jederzeit abrufbar, ohne dass jemand einen Export anstoßen oder Tabellen zusammenführen muss. Ändert sich ein Auftrag in SAP, zieht das Dashboard nach.
Tagesumsatz-Trend: Wie entwickeln sich die Verkäufe im Tagesverlauf? Saisonale Schwankungen, kurzfristige Ausreißer und aktuelle Entwicklungen sind sichtbar, sobald sie auftreten, und nicht erst, wenn der nächste Bericht erstellt wird.
Der Unterschied zum bisherigen Arbeitsablauf ist nicht nur eine Frage der Geschwindigkeit. Es geht auch um Verlässlichkeit: Anstatt auf einen manuell zusammengestellten Export zu warten, der zum Zeitpunkt der Lieferung bereits veraltet ist, öffnet man ein Dashboard und vertraut den angezeigten Daten.
Was das konkret bringt – für Business und IT
Ein Blick unter die Haube
Wer die Business-Perspektive sucht, ist mit den vorigen Abschnitten bestens bedient. Dieser Abschnitt richtet sich an alle, die wissen wollen, was technisch dahintersteckt.
Wer darüber hinaus konkret wissen möchte, wie eine Microsoft Fabric-Pipeline für die inkrementelle Erfassung, Transformation und Auswertung von SAP-Daten unter Verwendung der Medallion-Architektur konfiguriert wird, sollte sich den Artikel in unserem HelpCenter anschauen.
Landing Zone & Bronze Layer
Eine delta-fähige SAP-Schnittstelle (im Demo-Setup TableCDC) extrahiert Änderungen direkt aus SAP und schreibt sie als Parquet-Dateien in eine Medallion Lakehouse Architecture in Microsoft Fabric, konkret in den Lakehouse Landing-Bereich, strukturiert nach dem Schema Files/incremental/<Tabellenname>/. Jeder Extraktionslauf erzeugt eine neue, timestampbasierte Datei – bestehende Dateien werden nie überschrieben. Jede Datei enthält einen inkrementellen Batch: Inserts, Updates und Deletes aus SAP.
Von dort lädt eine Copy Data Activity die Parquet-Dateien per Upsert in Bronze Delta-Tabellen – eine Tabelle pro SAP-Quelle. Verarbeitete Dateien werden anschließend archiviert und aus dem Landing-Bereich entfernt, sodass jede Datei garantiert genau einmal verarbeitet wird.
Konfiguration
Eine zentrale pipeline-config.json definiert pro SAP-Tabelle drei Parameter: den Landing-Ordner (FolderName), den Namen der Ziel-Delta-Tabelle (TableName) sowie die Schlüsselspalten für den Upsert-Merge (KeyColumns, immer inklusive MANDT als SAP-Mandantenkennung). Eine neue Tabelle onboarden bedeutet: einen JSON-Eintrag ergänzen, keine Pipeline-Änderung.
Orchestrator- & Child-Pipeline
Der Orchestrator ist eine Microsoft Fabric Pipeline, die die Konfigurationsdatei per Lookup-Activity liest, per ForEach (parallel) über alle Tabelleneinträge iteriert und für jede Tabelle eine Child Pipeline aufruft . Sobald alle Bronze-Tabellen aktualisiert sind, triggert der Orchestrator ein Notebook, das Silver und Gold aufbaut.
Die Child Pipeline läuft einmal pro Tabelle: Sie listet per Get-Metadata-Activity die verfügbaren Parquet-Dateien, sortiert sie chronologisch, und verarbeitet sie in einem inneren ForEach einzeln – Copy Data (Upsert) → Archivierung → Notebook-Step für Deletes.
Explizites Delete-Handling
Die Copy Data Activity im Upsert-Modus unterstützt ausschließlich Insert und Update. Löschungen können nicht direkt verarbeitet werden. SAP-CDC-Extrakte signalisieren Löschungen über ein Delete-Flag im Datensatz. Ein dediziertes Notebook (nb clean deleted rows) gleicht nach jedem Copy-Data-Schritt die Bronze Delta-Tabelle gegen dieses Signal ab und entfernt die entsprechenden Zeilen. Ergebnis: Bronze bleibt ein akkurates Abbild des aktuellen SAP-Zustands, kein append-only Log.
Silver & Gold
Im zweiten Teil der Medallion Pipeline übernimmt ein einzelnes Notebook (nb transform sales analytics) den Aufbau der Silver- und Gold-Schicht, nachdem alle Bronze-Loads abgeschlossen sind. Silver konformiert die Rohdaten zu Business-Entitäten (Customer aus KNA1, SalesOrder aus VBAK + VBAP). Gold aggregiert diese zu reporting-fertigen Tabellen (CustomerRevenue, DailySales).
Semantic Model
Ein Power BI Semantic Model liegt direkt auf dem Gold Layer und zentralisiert die Geschäftslogik: DAX-Measures für Gesamtumsatz, Umsatz pro Kunde und periodenübergreifende Trendanalysen sind einmal definiert und stehen allen Reports zur Verfügung. Keine verteilte Logik, keine abweichenden Berechnungen.
Fazit
Eine deltafähige SAP-Schnittstelle, kombiniert mit einer konfigurationsgetriebenen Fabric-Medallion-Pipeline, verwandelt veraltete SAP-Exporte in ein verlässliches, automatisch aktualisiertes Live-Dashboard – ganz ohne manuelle Eingriffe, Batch-Fenster oder IT-Flaschenhälse.
Das hier beschriebene Setup ist keine theoretische Konzeption, sondern eine funktionsfähige Demo auf Basis echter SAP-Vertriebs- und Kundendaten. Wenn Sie dies in Aktion erleben möchten, können Sie gerne eine Demo anfragen. Wir zeigen Ihnen dann, wie die Pipeline läuft und wie das Ergebnis in Power BI aussieht.
