Die technische Architektur eines Datenprodukts beschreiben

Datenprodukte sind das Herzstück von SAP BDC. Sie sind die einzelnen Bausteine der Datenplattform und bestehen aus kuratierten Geschäftsdaten und zugehörigen Metadaten, die aus SAP- und Nicht-SAP-Anwendungen extrahiert wurden.

Für SAP-Quellanwendungen verwaltet SAP alle Aspekte des Extraktions-, Transformations- und Ladeprozesses (ETL-Prozesses) vom Quellsystem bis zum SAP-BDC-Objektspeicher, in dem die Daten abgelegt werden. Kunden nutzen einfach die sofort einsatzbereiten Datenprodukte. Ein Datenprodukt stellt geschäftsbereite Daten ohne Datenvorbereitungsaufgaben bereit, die von der IT-Organisation eines Kunden benötigt werden. Kunden können sich darauf konzentrieren, den von SAP ausgelieferten Datenprodukten durch Anreicherung einen Mehrwert zu bieten. Oder verwenden Sie sie einfach so, wie sie sind.

Jede SAP-Quellanwendung stellt die Daten für die Datenprodukte mithilfe ihrer eigenen nativen Technologie bereit. Beispielsweise verwendet SAP S/4HANA die ABAP-Technologie, bei der ABAP-Core-Data-Services-Views (CDS-Views) mehrere ABAP-Tabellen zu einer harmonisierten View kombinieren, die für die Extraktion bereit ist.

Datenprodukte sind leistungsstark, aber wenn sie nicht entdeckt werden können, sind sie nutzlos.

SAP-BDC-Datenprodukte werden mithilfe des von SAP entwickelten, offenen Standard-ORD-Protokolls (Open Resource Discovery) beschrieben und bereitgestellt.

Das ORD-Protokoll wurde ursprünglich von SAP entwickelt, um APIs zwischen Systemen bereitzustellen. Später wurde sie um SAP-BDC-Datenprodukte erweitert. ORD ist ein etabliertes Framework innerhalb der SAP-Business-AI-Plattform, das von Entwicklern verwendet wird, um APIs und Ereignisse aus SAP-Systemen zu entdecken.

Das Ziel von ORD im Kontext von SAP BDC besteht darin, Informationen zu Datenprodukten aus allen SAP-Quellanwendungen zu sammeln und sie über einen zentralen Katalog bereitzustellen. Der Anbieter muss sicherstellen, dass die Datei Datenproduktdefinition für jedes Datenprodukt die Schlüsselinformationen enthält, die der Aggregator über das Provider-API benötigt. Der Aggregator für SAP BDC ist der zentrale Katalog.

Das ORD-Protokoll enthält wichtige Auffindbarkeitsattribute wie Sichtbarkeit, Freigabestatus und Integrationsabhängigkeiten.

Wenn Sie mehr über das ORD-Protokoll erfahren möchten, klicken Sie hier: Guide to Open Resource Discovery (ORD)

Neben den Geschäftsdaten stellen SAP-BDC-Datenprodukte auch die wertvollen Metadaten bereit, die die Geschäftsdaten detailliert beschreiben.

Die Metadaten eines Datenprodukts liefern KI wichtige Informationen zur Bedeutung der Geschäftsdaten. Ohne Metadaten wären genaue und nützliche Ergebnisse aus KI schwer zu erreichen.

Zu den Metadaten gehören:

• Beschreibungen/Bezeichner für jedes Feld in verschiedenen Sprachen, z.B. hat das technische Feld R_001_10a den Bezeichner Gross Revenue auf Englisch und Revenu Brut auf Französisch.
• Identifikation des Feldes, das die Sprache für die Anzeige von Etiketten und Beschreibungen bereitstellt. Zum Beispiel das Land des Buchungskreises, der die Rechnung generiert.
• Geschachtelte Assoziation zu anderen Entitäten, z.B. ist das Produkt mit dem Lieferanten verknüpft, der mit dem Land verknüpft ist.
• Semantik, die die genaue Bedeutung der einzelnen Felder im Datenprodukt beschreibt, z.B. ist der Erlös ein Überwachungswert mit der Währung EUR.
• Regeln, die beschreiben, wie eine Kennzahl aggregiert werden soll und nicht aggregiert werden soll. Beispiel: Endbestandsmenge sollte nie mit Summe für dasselbe Produkt über Zeitdimensionen hinweg aggregiert werden, sondern stattdessen über die Zeit mit Last aggregiert werden.

Das CSN-Protokoll (Core Schema Notation) wird verwendet, um die Metadaten von SAP-BDC-Datenprodukten zu definieren.

CSN ist ein etabliertes Format zur Beschreibung von Entitäts- und Servicemodellen innerhalb des SAP-Partnernetzes. CSN verwendet ein JSON-Format, um Metadaten zwischen Systemen auszutauschen.

Wenn Sie mehr über CSN erfahren und ein detailliertes Beispiel sehen möchten, klicken Sie hier:

Foundation Services werden häufig als Backbone von SAP BDC bezeichnet.

Foundation Services spielen eine Schlüsselrolle bei der Generierung und Verwaltung von Datenprodukten. Der „Treibstoff" von SAP BDC.

Foundation Services sind die SAP-verwalteten Services hinter der Szene, die mehrere Zuständigkeiten haben, einschließlich:

• Daten aus SAP-Anwendungen extrahieren
• Transformation und Vereinheitlichung von Daten aus SAP-Anwendungen
• Generieren von Datenprodukten
• Einrichten der Erstdatenübernahme- und Deltadatenübernahmeprozesse
• Verwalten der Speicherung von Datenprodukten im Objektspeicher
• Teilen von Datenprodukten mit Verbraucheranwendungen
• Governance und Sicherheit von Datenprodukten

Kunden haben keinen Zugriff auf die Foundation Services. Was stattfindet, ist im Hintergrund und für Kunden unsichtbar. SAP überwacht ständig alle Aktivitäten in den Foundation Services der SAP-BDC-Landschaft eines Kunden, um sicherzustellen, dass die Daten ohne Unterbrechung von den Quellanwendungen in SAP BDC fließen.

Foundation Services ist eine obligatorische Komponente in einer SAP-BDC-Landschaft und Teil der bereitgestellten SAP-BDC-Kernkomponente.

Der Objektspeicher der Foundation Services basiert auf SAP HANA Cloud, Data Lake.

Verfolgen wir den Ablauf der Produktion eines Datenprodukts.

1. Um die Installation eines Datenprodukts anzustoßen, können Sie intelligente Inhalte installieren, die die erforderlichen Datenprodukte automatisch installieren, oder Sie können ein Datenprodukt manuell aus dem SAP-BDC-Cockpit installieren.
2. Die Orchestrierungsschicht der Foundation Services wird über die Installation informiert und startet den Generierungsprozess. Die Orchestrierungsschicht prüft die Datenprodukt-Registry, wo sie die Datenproduktdefinitionsdatei durchsucht, um herauszufinden, welches Quellsystem für jedes Datenprodukt verbunden werden soll.
3. Im Quellsystem gibt es eine Zuordnung zwischen jedem Datenprodukt und den Quelltabellen/-Views. Die Daten werden vom Quellsystem gesammelt und an die Aufnahmeschicht (repliziert) des Objektspeichers in den SAP BDC Foundation Services übertragen. Die Daten werden im Format des Quellsystems gespeichert.
4. Die Daten aus der replizierten Schicht durchlaufen Transformationen, die auf Spark-Pipelines basieren, um nutzungsbereite, stabile Datenprodukte in der verfeinerten Schicht zu generieren. Einige Datenprodukte können auch eine zusätzliche Schicht durchlaufen, um ein abgeleitetes Datenprodukt von der verfeinerten Schicht zur angereicherten Schicht zu generieren.
5. Schließlich wird das Datenprodukt über das ORD-Protokoll verfügbar gemacht, sodass es von Benutzern in der gesamten Kundenlandschaft entdeckt werden kann.

Die Datenprodukte von SAP BDC werden im Objektspeicher gespeichert. Der Objektspeicher ist eine Schlüsselkomponente in den SAP BDC Foundation Services.

Der Objektspeicher wird technisch mit SAP HANA Cloud, Data Lake implementiert. Im Data Lake werden die Daten über das Delta-Tabellenformat verwaltet, das das Delta-Share-Protokoll unterstützt. Die Daten werden in Dateien gespeichert - in der Regel Parquet-Dateien.

Der Data-Lake-Speicher ermöglicht es SAP BDC, sehr große Datenmengen mit Funktionen wie ACID-Transaktionen, skalierbarer Metadatenverarbeitung und einheitlichem Streaming und Batch-Datenverarbeitung effizient zu verwalten. Dieser Ansatz ist kostengünstig und hochskalierbar und unterstützt Speicher und Verarbeitung in mehreren Terabyte.

Wenn Sie Daten freigeben, anstatt sie zu kopieren, vermeiden Sie unkontrollierte Datensilos. Wenn Sie ein einzelnes Datenset für alle Anwendungen freigeben, behalten Sie die Kontrolle darüber, wer Zugriff auf die Daten hat, und Sie sind immer sicher, dass die Daten als zentrale Datengrundlage vertrauenswürdig sind.

In SAP BDC werden Datenprodukte über das Delta-Sharing-Protokoll geteilt. Das Delta-Share-Protokoll ist eine weit verbreitete Open-Source-Technologie, die den Datenzugriff ermöglicht:

• ohne Daten zu verschieben oder zu kopieren. Dies wird durch einen Nullkopieransatz erreicht.
• durch eine Vielzahl von Methoden, um die meisten Verbrauchstools zu unterstützen.
• mit einer zentralen Governance, die die Datensicherheit gewährleistet.
• auf eine hochgradig skalierbare Weise.

Der Datenanbieter teilt ausgewählte Daten und verwaltet den Zugriff über einen Sharing-Server, der das Delta-Sharing-Protokoll verwendet.

Der Datenkonsument muss einen der vielen Delta-Sharing-Clients verwenden, die das Protokoll unterstützen. Einige Open-Source-Konnektoren wurden freigegeben, z.B. für Apache Spark und Python.

Das Protokoll stellt sicher, dass sich der Client beim Sharing-Server authentifiziert und dass er berechtigt ist, auf die in der Abfrage angeforderten Daten zuzugreifen. Anschließend protokolliert es die Anforderung und ermittelt, welche Daten zurückgesendet werden sollen. Der Sharing-Server legt dann temporäre URLs für den Client an, um Dateien direkt vom Cloud-Anbieter herunterzuladen. Dieser Prozess ermöglicht eine schnelle, umfangreiche Datenübertragung, ohne den Sharing-Server zu durchlaufen, was sie effizient und kostengünstig macht.

Weitere Informationen zum Delta-Sharing finden Sie hier: Deep Dive on Delta Share

• Sie haben gelernt, wie sich Datenprodukte mithilfe des ORD-Protokolls selbst beschreiben.

• Sie haben gelernt, wie CSN-Dateien die Metadaten der Datenprodukte bereitstellen.

• Sie haben gelernt, wie Foundation Services die Datenprodukte verwalten und eine Speicherkomponente bereitstellen, die als Objektspeicher bezeichnet wird und auf einer Data-Lake-Architektur basiert.