SAP Datasphere und das virtuelle Datenmodell (VDM) von SAP S/4HANA

Das virtuelle Datenmodell (VDM) von SAP S/4HANA bietet eine semantisch reichhaltige Layer über den unbearbeiteten HANA-Tabellen und ermöglicht so Analysen und Integrationen, ohne die zugrunde liegenden Schemata offenzulegen. Durch die Organisation der Geschäftslogik in wiederverwendbaren CDS-Views gewährleistet das VDM Konsistenz, Stabilität bei Upgrades und Out-of-the-Box-Kompatibilität mit Tools wie SAP Datasphere.

In diesem Artikel erfahren Sie, was das VDM ist, wie es funktioniert und warum sich das VDM so gut mit SAP Datasphere kombinieren lässt.

Was ist das virtuelle Datenmodell von SAP S/4HANA?

Im Kern ist das VDM die „semantische Schicht“ der SAP in S/4HANA, eine Abstraktion, die vollständig mit ABAP Core Data Services (CDS)-Views aufgebaut ist. Anstatt Abfragen an Roh-Tabellen (z. B. VBAK oder VBAP) zu senden, werden aussagekräftige Business-Entitäten wie beispielsweise SalesOrder oder BillingDocument verwendet.

Diese CDS-Views definieren, welche Spalten und Assoziationen angezeigt werden, wie Felder umbenannt oder berechnet werden und welche Filter gelten.

Alle Views unterliegen strengen Namenskonventionen und Layering-Regeln. SAP garantiert außerdem die Upgrade-Stabilität durch das auf „Stability Contracts“ basierende Erweiterung Framework. Andere Anwendungen (z. B. Datasphere) können auf speziell definierte Views zugreifen, um S/4 HANA-Daten performant und zukunftssicher zu konsumieren.

Ein wenig Theorie zu CDS-Views

Das VDM stützt seine Best Practices für die Modellierung auf einen Layer-Ansatz, der Aufgaben trennt und die Wiederverwendung fördert. Es gibt viele Arten von CDS-Views, die unterschiedlichen Zwecken dienen, aber sehen wir uns die grundlegendsten einmal genauer an:

• Basic Views: Dies sind Views, die der Tabellenstruktur sehr ähnlich sind und Felder zur besseren Übersichtlichkeit umbenennen sowie einen geschäftlichen Kontext hinzufügen. Diese Views werden hauptsächlich verwendet, um die Tabellendaten für die weitere Verwendung bereitzustellen. SAP verwendet gemäß seiner Namenskonvention „I“ als Präfix im View-Namen. Anmerkungen wie (@VDM.viewType: #BASIC) werden verwendet, um einen Basic View zu kennzeichnen.
• Composite Views: Diese Views verbinden und aggregieren Basic Views zu umfassenderen Business-Entitäten. Die dafür verwendete Anmerkung lautet (@VDM.viewType: #COMPOSITE).
• Consumption Views: Consumption Views werden streng auf anderen Views (niemals auf Tabellen) aufgebaut und passen Daten an bestimmte Szenarien an (eingebettete Analysen in Fiori-Apps, benutzerdefiniertes Reporting oder OData-Services). Die Namenskonvention beginnt generell mit: C_*.

Die folgende Abbildung zeigt am Beispiel von Kundenaufträgen, wie das VDM funktioniert.

Anpassung und Erweiterbarkeit

Für Fälle, in denen eine Anpassung erforderlich ist, ermöglicht das VDM Erweiterungen der CDS-Views. Dabei handelt es sich um separate technische Objekte, die nur die zusätzlichen Felder definieren, die zu einer bestimmten CDS-View hinzugefügt werden sollen. Die ursprüngliche View bleibt unverändert, was eine einfachere Wiederverwendung und Stabilität bei S/4HANA-Upgrades gewährleistet. Zusätzlich kann eine neue View von Grund auf auf anderen veröffentlichten CDS-Views aufgebaut werden, um größere Anpassungen zu ermöglichen, z.B. das Zusammenführen zweier Modelle.

Zu diesem Zweck spielen Stability Contracts eine entscheidende Rolle, da sie beschreiben, welche Art von Upgrade-Stabilität SAP für die Views in ihrem VDM garantiert.

Es gibt drei Arten von Verträgen:

• C0 (Key-User-Erweiterbarkeit)
  Diese Art von Vertrag ermöglicht grundlegende Felderweiterungen über Key-User-Tools.
  
  
• C1 (Systeminterne Verwendung)
  Diese Art ist für kundenspezifische Entwicklungen üblich; SAP stellt sicher, dass die meisten Schnittstellenelemente über Releases hinweg stabil bleiben.
  
  
• C2 (Remote-API-Nutzung)
  Diese Art von Vertrag bietet die höchste Stabilitätsgarantie, da sie für externe Integrationen und veröffentlichte APIs vorgesehen ist.

Wir empfehlen, diese Stability Contracts so genau wie möglich einzuhalten, jedoch lässt sich eine Verletzung manchmal nicht vermeiden. Man muss sich jedoch der damit verbundenen Risiken bewusst sein:

Man stellt sich vor, dass eine benutzerdefinierte CDS-View auf Basis einer VDM-CDS-View erstellt wurde. Die Organisation aktualisiert dann die S/4 HANA-Version auf einen neuen Release. Mit diesem neuen Release hat SAP sein VDM geändert und ein Feld (gemäß dem gepflegten Stability Contract C0), welches in der benutzerdefinierten CDS-View verwendet wurde, entfernt oder umbenannt. Nun wird der S/4-Upgrade-Prozess aufgehalten, bis diese fehlerhafte Definition in der benutzerdefinierten CDS-View behoben ist.

Warum passen SAP Datasphere und das Virtual Data Model (VDM) so gut zusammen?

Metadaten mit Semantic Onboarding intakt halten

SAP Datasphere und das S/4HANA Virtual Data Model (VDM) lassen sich nahtlos miteinander integrieren, da Datasphere die ABAP CDS-basierten Metadaten und semantischen Definitionen nutzen kann und so sicherstellt, dass der S/4-Geschäftskontext nach dem Import der Modelle in Datasphere erhalten bleibt.

Durch die Verwendung von Replication Flows zur Replikation aus S/4HANA können lokale Zieltabellen automatisch erstellt werden, wobei die Felddefinitionen aus den CDS-Views abgeleitet werden, wodurch ein Teil ihrer Semantik wie Geschäftsnamen und Datentypen erhalten bleibt und Entwicklungszeit gespart wird.

Für eine schnelle Entwicklung von Modellen kann die Semantic Onboarding-Funktion genutzt werden, mit der sich das CDS-basierte virtuelle Datenmodell von SAP S/4HANA direkt in SAP Datasphere einbinden lässt, sodass die in S/4 definierten semantisch reichhaltigen Entitäten ohne manuelle Nachbearbeitung in Datasphere erscheinen.

In der Praxis liest Datasphere die Metadaten jeder View (Kennzahlen-definitionen, Einheiten- und Währungsannotationen, Feldbezeichnungen, Texte und Assoziationen) und generiert automatisch entsprechende Objekte im Datasphere-Space, die die gesamte im VDM eingebettete Geschäftslogik beibehalten. Dies spart enorm viel Zeit und beschleunigt die Entwicklung von Datenmodellen. Außerdem dient es als perfekte Datengrundlage für KI-Anwendungen, die von miteinander verbundenen Systemen und umfangreichen Metadaten profitieren.

Sehen Sie sich die Aufzeichnung unseres Webinars an: 
"SAP Datasphere and the Databricks Lakehouse Approach"

Vereinfachen Sie die Datenintegration mit Change Data Capture

Darüber hinaus liefern CDS-Views, die durch Annotationen Change Data Capture fähig sind, automatisch Deltas. Die Replication Flows von Datasphere nutzen diese Deltainformationen automatisch, wodurch Datenbewegungen und Latenzen minimiert werden.

Eine zwingende Voraussetzung für die Verwendung von CDS-Views für die Extraktion nach Datasphere ist die Annotation @dataExtraction.enabled: true.

Um eine Echtzeit-Replikation von Daten zu unterstützen, können CDS-Views auf folgende Weise für Change Data Capture aktiviert werden:

• Automatic CDC-Annotation
  Automatic CDC funktioniert gut, wenn CDS-Views direkt auf Tabellen (ohne zusätzliche Join-Bedingungen) liegen.
  Durch Hinzufügen von @ChangeDataCapture.automatic: true zu einer CDS-View wird der Mechanismus angewiesen, Inserts, Updates und Deletes zu verfolgen.

• Mapping und Joins
  Für Views, die Schlüssel umbenennen oder Joins enthalten, verwendet man die @ChangeDataCapture.mapping-Annotation, um das Mapping zu den Basistabellenschlüsseln zu formalisieren..

SAP Business Content

Darüber hinaus ist SAP Datasphere mit vorgefertigten Business-Content-Paketen ausgestattet, die vordefinierte Modelle und KPIs enthalten, wie z. B. „Sales Analysis“ und „Finance Foundation for SAP S/4HANA“, die auf dem VDM für diese Bereiche basieren. Durch die Nutzung dieser Pakete können Unternehmen schnell und ohne großen Aufwand komplexe Datenmodelle generieren.

Aus unserer Erfahrung heraus empfehlen wir, den Business-Content als Ausgangspunkt für die Modellierung zu nutzen, jedoch nicht einfach unverändert zu übernehmen, da dieser in vielerlei Hinsicht mit zahlreichen Layern überkompliziert ist und an anderer Stelle Details fehlen.

Aus diesem Grund sollten die Standardmodelle aus dem Content eher als Grundlage für die individuelle Modellierung dienen. Durch die Untersuchung des Contents können Datenmodellierer ein Verständnis dafür entwickeln, wie Daten und Tabellen aus S/4 HANA miteinander korrelieren, um KPIs zu erstellen und diese Logik in einer konsolidierten Form neu aufzubauen. Auf diese Weise können die unternehmensspezifischen Governance-Standards sowie die spezifischen Geschäftsanforderungen realisiert werden, anstatt den generischen Business Content zu verwenden.

Limitationen

Obwohl SAP Datasphere und SAP S/4HANA eindeutig aufeinander abgestimmt sind, gibt es dennoch einige Einschränkungen, die die Handhabung etwas erschweren.

Ein Faktor ist, dass die Replikation zwischen S/4 und Datasphere die Implementierung einer Vielzahl von SAP-Notes erfordert, insbesondere bei älteren S/4-Versionen. Diese reichen von absolut erforderlichen Notes bis hin zu Änderungen, die den Komfort verbessern und die Monitoring Funktionen erweitern.

Darüber hinaus kann das Monitoring der Replication Flows über den Datenintegrationsmonitor etwas einschränkend sein, da viele der angezeigten Fehler sehr allgemein gehalten sind und nicht viele Details liefern. Die weitere Fehlerbehebung solcher Laufzeitfehler kann über den S/4HANA-T-Code SLG1 erfolgen, mit dem der Application Log auf detailliertere Meldungen überprüft wird.

Mit den T-Codes DHRDBMON (für beide Ladetypen) und DHCDCMON (für den Ladetyp „Initial und Delta“) kann der Buffer Table Status der Quellobjekte sowie der CDC-Monitor im S/4-System überprüft werden, wodurch die Datasphere Replication Flows überwacht und Fehler behoben werden können. Die Möglichkeiten zur Fehlerbehebung sind jedoch nach wie vor begrenzt und erfordern oft fundierte technische Kenntnisse und umfassende Berechtigungen im Quellsystem.

Zusammenfassung und Ausblick

Das exzellente Zusammenspiel zwischen Datasphere und S/4HANA wird vor allem erreicht durch die konsistente Übertragung von Metadaten und semantischen Definitionen, schnellen Wertschöpfungsfunktionen wie dem Semantic Onboarding, aufeinander abgestimmten Business Content zwischen S/4HANA, Datasphere und SAC, einem guten Erweiterungskonzept mit den vorgelieferten virtuellen Datenmodell und C0/1/2 Stability Contracts, sowie schließlich einem leistungsstarken und wartungsarmen CDC-Framework für die Datenintegration.

Bei Verwendung älterer S/4HANA-Versionen sind jedoch weiterhin umfangreiche manuelle Konfigurationen erforderlich, obwohl in den letzten Releases kontinuierliche Verbesserungen eingeführt wurden. Generell unterliegen die integrierten Monitoring- und Troubleshooting Funktionen einigen Limitationen.

Mit Blick auf die Zukunft wird die Kombination aus S/4HANA und Datasphere (und damit auch Business Data Cloud) immer wichtiger, um eine solide Datenbasis für KI-Anwendungen (Joule) und -Anwendungsfälle zu schaffen.

Haben Sie Fragen zu SAP Datasphere? Oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Wir helfen Ihnen gerne dabei. Nehmen Sie einfach Kontakt zu uns auf!