Integration von SAP-Daten in Microsoft Fabric

Mit dem richtigen Integrationsmuster zur optimalen Anbindung von SAP-Daten an Microsoft Fabric

Die Integration von SAP-Daten in Microsoft Fabric erfordert eine bewusste Auswahl des passenden Integrationsmusters. Dabei stellen sich insbesondere zwei zentrale Fragen:

• Welches Integrationsmuster unterstützt die fachlichen Anforderungen am besten?

• Welche technischen und organisatorischen Rahmenbedingungen auf SAP-Seite müssen berücksichtigt werden?

  
  

In der Praxis lassen sich die meisten Analytics-Szenarien auf zwei grundlegende Integrationsmuster zurückführen:

• Periodische Full Loads (Snapshots)

• Delta-basierte Extraktionen bei relevanten Änderungen

  
  

SAP stellt für beide Fälle klar definierte Mechanismen bereit, die sich unterschiedlich auf Microsoft Fabric abbilden lassen.

1) Periodische Full Loads (Snapshots)

Für viele analytische Szenarien ist es ausreichend, Daten regelmäßig vollständig zu laden. Gemeint sind dabei zustandsorientierte Auswertungen, bei denen der fachliche Fokus auf einem konsistenten Stichtag liegt und nicht auf der lückenlosen Nachverfolgung einzelner Änderungen.

Das betrifft insbesondere Szenarien, bei denen:

• die fachliche Aussage ein periodischer Zustand ist und kein Änderungsverlauf

• eine tägliche oder mehrmals tägliche Aktualisierung ausreichend ist

• vollständige Reloads technisch beherrschbar bleiben

  
  

Dieses Integrationsmuster ist sowohl für SAP ECC als auch für SAP S/4HANA geeignet, da es auf einem generischen SAP-Mechanismus basiert, der unabhängig vom zugrunde liegenden Datenmodell funktioniert.

SAP unterstützt Full-Loads über den direkten Zugriff auf Tabellen oder Views via RFC.

Die Extraktion ist damit bewusst technisch einfach gehalten. Die Verantwortung für Zeitbezug, Historisierung oder Aggregation liegt vollständig außerhalb von SAP.

In Microsoft Fabric wird dieses Muster typischerweise über den SAP Table Connector in Fabric Data Factory umgesetzt. Die Extraktion liefert vollständige Snapshots, die im Lakehouse oder Warehouse weiterverarbeitet werden.

Dieser Ansatz ist dann sinnvoll, wenn:

• Datenvolumen und Laufzeiten kontrollierbar bleiben

• keine fachliche Notwendigkeit besteht, jede einzelne Änderung separat abzubilden

  
  

Sobald sich diese Rahmenbedingungen ändern, stößt das Full-Load-Muster an seine Grenzen.

2) Delta-basierte Extraktion

Delta-basierte Extraktion wird erforderlich, sobald Änderungen fachlich relevant sind und nicht nur der Zustand, sondern auch die Veränderung selbst analysiert werden soll. Das betrifft insbesondere Szenarien mit laufenden Bewegungen, Statuswechseln oder historisierten Attributen.

Typische fachliche Auslöser sind:

• häufige Änderungen an Geschäftsvorfällen

• fachliche Notwendigkeit zur Historisierung von Zuständen

• technische oder organisatorische Grenzen bei vollständigen Reloads

  
  

Dieses Integrationsmuster ist für SAP ECC und SAP S/4HANA vorgesehen. In beiden Systemen stellt SAP mit ODP einen einheitlichen Mechanismus für inkrementelle Bereitstellung bereit.

SAP sieht für diese Anforderungen das Operational Data Provisioning Framework (ODP) vor. ODP stellt:

• SAP-definierte Extraktoren

• Delta-Queues zur inkrementellen Abholung

• eine fachlich konsistente Änderungslogik bereit.

Die Verantwortung dafür, was eine relevante Änderung ist, verbleibt damit im SAP-System.

Microsoft Fabric kann ODP-basierte Deltas über den SAP CDC Connector verarbeiten. Fachlich ist dies der vorgesehene Weg für inkrementelle Szenarien aus SAP ECC und SAP S/4HANA.

Gleichzeitig ist dieser Ansatz immer im Kontext der SAP-seitigen Nutzungs- und Compliance-Vorgaben zu bewerten. Insbesondere SAP Note 3255746 adressiert den Zugriff auf ODP Data Replication APIs durch Drittplattformen. In der Praxis bedeutet das, dass der Einsatz dieses Mechanismus häufig einer organisatorischen Prüfung unterliegt, unabhängig davon, ob er fachlich sinnvoll wäre.

Wenn ein direkter Zugriff auf ODP-Queues durch externe Plattformen nicht vorgesehen oder nicht freigegeben ist, haben sich zwei Integrationsmuster etabliert:

• SAP-nahe Extraktionsschichten über spezialisierte Anbieter, bei denen Delta-Logik kontrolliert außerhalb von Fabric, aber SAP-nah umgesetzt wird

• SAP Datasphere als Outbound-Layer, der Daten SAP-konform nach Azure Data Lake Storage Gen2 bereitstellt und von Fabric über Shortcuts konsumiert wird

Beide Muster adressieren delta-basierte Anforderungen, ohne dass Microsoft Fabric selbst direkt auf ODP-Queues zugreift.

Fazit

Die Integration von SAP-Daten nach Microsoft Fabric folgt klar unterscheidbaren Integrationsmustern, die sich aus der fachlichen Anforderung, dem SAP-Quellsystem und den organisatorischen Rahmenbedingungen ableiten:

• Periodische Full Loads (Snapshots) empfehlen sich, wenn zustandsorientierte Auswertungen im Vordergrund stehen und eine regelmäßige vollständige Aktualisierung fachlich ausreichend ist. In Microsoft Fabric ist hierfür der RFC-basierte Tabellenzugriff über Fabric Data Factory der naheliegende Standard, insbesondere für SAP ECC und SAP S/4HANA bei beherrschbarem Datenvolumen.

• Delta-basierte Integrationsmuster sind erforderlich, sobald Änderungen selbst fachlich relevant werden oder Historisierung benötigt wird. Für diese Szenarien ist ODP der von SAP vorgesehene Mechanismus für SAP ECC und SAP S/4HANA, der eine konsistente Änderungslogik im SAP-System sicherstellt.

  • ODP-basierte Extraktion in Microsoft Fabric kann über den SAP CDC Connector umgesetzt werden, unterliegt jedoch organisatorischen und lizenzseitigen Bewertungen im Kontext der SAP-seitigen Nutzungsbedingungen.

  • SAP-nahe Integrationsansätze, etwa über spezialisierte Extraktionslösungen oder über SAP Datasphere als Outbound-Layer, ermöglichen delta-basierte Szenarien auch dann, wenn ein direkter Zugriff auf ODP-Queues durch externe Plattformen nicht vorgesehen ist.