Konzeptkarte

Microsoft Fabric & SAP-Integration

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Microsoft Fabric & SAP-Integration?

Vier Integrationsmuster von SAP zu Fabric funktionieren (Mirroring, Data-Factory-Konnektoren, Delta Sharing, OData); zwei, die Teams immer wieder versuchen — direktes ODBC und umgekehrtes Mirroring von Fabric zu Datasphere — sind nicht unterstützt oder 2026 schlicht noch nicht GA.

Was es ist

Microsoft Fabric ist Microsofts einheitliche Analytics-Plattform, die OneLake als gemeinsame Speicherschicht mit Data Factory, Synapse Engineering, Synapse Data Warehousing, Data Science, Real-Time Analytics und Power BI unter einem einzigen SaaS-Abonnement bündelt. Für einen SAP-Analytics-Berater ist der im Tagesgeschäft tatsächlich relevante Teil enger gefasst als die gesamte Plattform: die spezifische Integrationsfläche zwischen SAP und Fabric — vier Muster, die in der Produktion wirklich funktionieren, und zwei Muster, die Fabric-Nutzer immer wieder versuchen, die aber nicht funktionieren.

Warum es wichtig ist

Die Fabric-Einführung in Unternehmen, die bereits SAP betreiben, ist inzwischen so verbreitet, dass 'Wie bringen wir SAP-Daten in Fabric, ohne die Governance zu brechen?' eine wiederkehrende Architekturfrage ist, kein Randfall. Die falsche Musterwahl ist doppelt teuer — einmal durch Engineering-Aufwand für eine Pipeline, die nicht skaliert, und ein zweites Mal durch Fabric-Capacity-Unit-Ausgaben, die niemand vorab modelliert hat.

Warum es zählt

Delta Sharing verursacht null Capacity-Unit-Kosten auf Fabric-Seite, da die Daten in Datasphere verbleiben — das macht es zum Muster mit den niedrigsten Gesamtbetriebskosten für lesehungrige, selten aktualisierte Fälle.
Der CU-Verbrauch von Mirroring wird auf Fabric-Seite gemessen — ein alle 5 Minuten gespiegelter BW/4HANA-InfoProvider kann bei Produktionsvolumen einen unverhältnismäßig großen Anteil einer F64-Capacity aufzehren.
Umgekehrtes Mirroring (Fabric schreibt zurück nach Datasphere) ist nur eine angekündigte Richtung, kein lieferbares Muster für 2026 — architektonisch noch nicht darauf aufbauen.

Kernpunkte

Mirroring — SAP-HANA-Cloud-/BW/4HANA-/Datasphere-Objekte werden als Delta-Tabellen nach OneLake repliziert; latenzarmes CDC; keine ETL-Pipeline zu pflegen.
Data-Factory-SAP-Konnektoren — SAP Table, SAP BW Open Hub, SAP HANA, SAP CDC für Batch-Ingestion in das Fabric-Lakehouse.
Open Delta Sharing — SAP Datasphere veröffentlicht einen Share; Fabric liest ihn als OneLake-Shortcut; DAC wird an der Share-Grenze durchgesetzt; niedrigste Fabric-CU-Kosten (Daten verbleiben in Datasphere).
OData-Konsum — Fabric Dataflow Gen2 ruft SAP-OData-Dienste auf; operative Integration mit geringem Volumen; nicht geeignet für Analytics-Volumen.
Anti-Muster 1: direktes ODBC vom Fabric-Notebook zu SAP HANA — funktioniert technisch, null Governance und Lineage, kein Fabric-Audit-Trail, in der Produktion nicht unterstützt.
Anti-Muster 2: umgekehrtes Mirroring Fabric → Datasphere — 2024 angekündigt, 2026 nicht GA; einem Kunden dies nicht als Liefergegenstand für 2026 versprechen.
CU-Kostenfalle: hochfrequentes Mirroring bei Produktionsvolumen eines BW/4HANA-InfoProviders kann einen unverhältnismäßig großen Anteil eines F64-SKU verbrauchen — vor der Festlegung mit repräsentativen Daten messen.
Delta Sharing ist das Muster mit den niedrigsten Gesamtbetriebskosten für lesehungrige, selten aktualisierte Datensätze: kein Fabric-CU-Verbrauch, governter Zugriff, Daten bleiben in Datasphere.
Musterentscheidung: Mirroring für latenzarmes Power BI · Data Factory für Batch-ETL · Delta Sharing für plattformübergreifenden governten Austausch bei niedrigen Gesamtbetriebskosten.
Die Musterwahl bestimmt sowohl die Integrationsarchitektur als AUCH das Kostenmodell — stimmen Sie das Fabric-SKU und das CU-Budget mit dem Azure-Team des Kunden ab, bevor Sie das Design finalisieren.

Begriffe auf dieser Seite

OneLake: Der einheitliche Data Lake von Microsoft Fabric — jeder Fabric-Tenant besitzt genau ein OneLake; alle Fabric-Workloads (Lakehouse, Warehouse, Power BI, Data Science) lesen und schreiben denselben Lake unter einem einzigen Zugriffsmodell.
Mirroring: Das Fabric-Muster der latenzarmen Replikation aus einer Quelldatenbank als Delta-Tabellen nach OneLake, ohne eine ETL-Pipeline zu betreiben; Mirroring für SAP HANA Cloud, BW/4HANA und Datasphere 2024 angekündigt, mit schrittweiser GA 2025.
OneLake-Shortcut: Ein Verweis von einem OneLake-Speicherort auf einen anderen oder auf eine externe Quelle (S3, ADLS, Delta Sharing); ermöglicht Fabric-Workloads, Daten vor Ort zu lesen, ohne sie zu kopieren — der Mechanismus hinter der Delta-Sharing-Integration mit SAP Datasphere.
Fabric Capacity (F-SKU): Das Preismodell von Microsoft Fabric basierend auf Capacity Units (CU); die hochfrequente SAP-zu-Fabric-Synchronisation über Mirroring verbraucht erhebliche CU und muss vor der Finalisierung der Architektur gegen das F-SKU bemessen werden.
Delta Sharing: Ein offenes Protokoll (Linux Foundation) zum plattformübergreifenden Teilen von Live-Daten, ohne sie zu kopieren; SAP Datasphere kann Delta Shares veröffentlichen, die Fabric als OneLake-Shortcuts liest — das Muster mit den niedrigsten Gesamtbetriebskosten für SAP-zu-Fabric 2026.
SAP-BW-Open-Hub-Konnektor: Ein Fabric-Data-Factory-Konnektor, der aus einer BW/4HANA-Open-Hub-Destination (OHD) liest und die Batch-Extraktion von InfoProvider-Inhalten in ein Fabric-Lakehouse ohne direkten Datenbankzugriff ermöglicht.
Data Access Control (DAC): Die zeilen- und objektbasierte Sicherheitsschicht von SAP Datasphere. Wenn Datasphere einen Delta Share veröffentlicht, werden DACs an der Share-Grenze durchgesetzt — Fabric-Konsumenten sehen nur die Zeilen, für die ihr Delta-Sharing-Bearer-Token autorisiert ist.
SAP-CDC-Konnektor: Ein Fabric-Data-Factory-Konnektor, der Change Data Capture (CDC) gegen SAP-HANA-Cloud- oder S/4HANA-Tabellen implementiert und nahezu-Echtzeit-inkrementelle Ladevorgänge in das Fabric-Lakehouse ohne vollständige Tabellen-Scans ermöglicht.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →