Virtual Data Model und CDS-Views – Ein Blick hinter die Kulissen von SAP S/4HANA Embedded Analytics

SAP S/4HANA Embedded Analytics stellt Unternehmen eine umfangreiche integrierte Berichtsplattform zur Analyse von Daten im operativen Geschäft zur Verfügung - ein zentraler Baustein moderner BI-Strategien. Durch vorgefertigte oder individuell entwickelte Reports und Dashboards lässt sich in Echtzeit ein messbarer Mehrwert für Business-Anwender erzielen. Den technikaffinen Benutzern stellt sich jedoch schnell die Frage, wie der technische Aufbau von SAP S/4HANA Embedded Analytics aussieht und welche Komponenten zusammenspielen, um maßgeschneiderte, reibungslos funktionierende Reports mit SAP S/4HANA Embedded Analytics zur Verfügung stellen zu können.

Dieser Blogbeitrag liefert einen fundierten Überblick über die wichtigsten technischen Komponenten aus Sicht von IT-Usern und Key-Usern („Analytics Specialists“) in SAP S/4HANA Embedded Analytics - insbesondere das Virtual Data Model (VDM) und die Core Data Services (CDS) Views, die den Kern der Datenmodellierung und Analytics-Funktionalität innerhalb von SAP S/4HANA bilden – ein Muss für jede zukunftsgerichtete Business Intelligence-Strategie.

Virtuelles Datenmodell

Im Zentrum von SAP S/4HANA Embedded Analytics steht die Nutzung operativer Daten in analytischen Anwendungen. Doch wie werden diese Daten aus den SAP S/4HANA-Datenbanktabellen für Reporting und Analyse nutzbar gemacht? Die Antwort lautet: mittels eines mehrschichtigen Virtual Data Models (VDM), das mit Hilfe von ABAP CDS Views aufgebaut wird.

Die Daten liegen in Datenbanktabellen ab, die – in einem simplen Szenario – den Applikationen möglicherweise direkt zur Verfügung gestellt werden könnten. In den meisten Anwendungsfällen ist man jedoch nicht nur an dem Inhalt einer einzigen Tabelle interessiert, da die Datenbanktabellen oft nur Stamm- oder Bewegungsdaten eines konkreten geschäftlichen Vorgangs speichern. Häufig müssen Daten daher aus einer Vielzahl an Datenbanktabellen verknüpft werden, um die gewünschten Einblicke erlangen zu können. Hier kommt das virtuelle Datenmodell zum Tragen: Schicht für Schicht wird basierend auf den Datenbanktabellen ein Modell aus ABAP CDS Views errichtet, die teilweise von anderen Views wiederverwendet werden können oder sich auf einen bestimmten thematischen Bereich gemäß der Geschäftssemantik fokussieren, um analytischen Anwendungen Daten virtuell zur Verfügung stellen zu können - ein zentraler Erfolgsfaktor jeder modernen BI-Strategie im SAP-Kontext.

Das virtuelle Datenmodell lässt sich auf Grundlage der gewünschten Verwendung einer CDS-View in folgende Schichten unterteilen:

Wiederverwendungsview-Schicht
Consumption-View-Schicht

Grafische Darstellung des dreischichtigen Aufbaus des Virtual Data Models (VDM) in SAP S/4HANA. Die unterste Ebene zeigt die SAP S/4HANA Datenbanktabellen. Darüber liegt die Wiederverwendungsschicht mit Basic- und Composite-Interface-Views. An oberster Stelle befindet sich die Consumption-View-Schicht mit den Endanwender-orientierten Consumption-Views. — Abbildung 1 - Das (vereinfachte) Virtual Data Model

Wiederverwendungsview-Schicht

Die erste Schicht des VDM oberhalb der Datenbanktabellen ist die Wiederverwendungsview-Schicht. Diese Schicht lässt sich wiederum in zwei Arten von Views unterteilen: Basic-Interface-Views und Composite-Interface-Views.

Basic-Interface-Views bauen unmittelbar auf zugrundeliegenden Datenbanktabellen auf und sind gleichzeitig auch die einzigen Views innerhalb des VDM, die unmittelbaren Zugriff auf Datenbanktabellen besitzen können. In dieser Schicht können technische, schwer verständliche Spaltennamen in geschäftssemantisch sinnvolle Begriffe überführt werden. Darüber hinaus können Basic-Interface-Views um Metadaten angereichert werden, etwa Annotationen und Relationen zu anderen Views. Die Zugehörigkeit der Views des VDM zu den jeweiligen Schichten erfolgt ebenfalls mithilfe von Annotationen. Die Annotation @VDM.viewType: #BASIC ist verpflichtend, um eine Basic-Interface-View als solche auszuweisen.
Composite-Interface-Views hingegen basieren auf Basic-Interface-Views und anderen Composite-Interface-Views und besitzen keinen Zugriff auf die Datenbanktabellen. Durch die Kombination mehrerer zugrundeliegender Views können so unter anderem analytische Cube-Views erstellt werden. Ein weiteres Anwendungsbeispiel ist die thematische Fokussierung einer Composite-Interface-View durch Integration berechneter Spalten, während die zugrundeliegende View für andere Szenarien möglichst generisch und allgemein bleibt. Composite-Interface-Views besitzen die Annotation @VDM.viewType: #COMPOSITE.

TIPP: Ob eine View Stammdaten, Bewegungsdaten oder verknüpfte Daten im Sinne eines Cubes bereitstellt, kann durch die Analyseannotation @Analytics.dataCategory dokumentiert werden. Mögliche Werte sind #DIMENSION für Stammdaten, #FACT für Bewegungsdaten und #CUBE für analytische Cubes.

Consumption-View-Schicht

Die Consumption-View-Schicht ist die oberste Schicht des VDM. Consumption-Views können auf Views der Wiederverwendungsview-Schicht zugreifen und diese mit Fokus auf eine konkrete Verwendung kombinieren und erweitern. Die Views dieser Schicht werden so entworfen, dass sie von transaktionalen und analytischen Anwendungen konsumiert werden können. Die erforderliche Annotation für Consumption-Views ist @VDM.viewType: #CONSUMPTION.

TIPP: „Unterstützte Funktionen“ und „Modellierungsmuster“ stellen zwei Arten der Annotation dar, mithilfe derer der Verwendungszweck einer View dokumentiert werden kann. Die Annotation ist nicht verpflichtend, kann aber hilfreich sein, um insbesondere in komplexeren Szenarien geeignete Views ausfindig zu machen. Ein einzelner Hauptverwendungszweck einer View kann mithilfe des Modellierungsmusters (@ObjectModel.modelingPattern) erfasst werden. Eine View kann jedoch mehrere unterstützte Funktionen (@ObjectModel.supportedCapabilities) besitzen. Beispiel: Die Funktion „SQL_DATA_SOURCE“ gibt an, dass die View als Datenquelle in einer SQL-Select-Anweisung geeignet ist.

Namenskonventionen und Semantik im CDS-Kontext

Um einen möglichst hohen Grad an Verständlichkeit zu erzielen, sollte die Benennung der CDS-Views und der enthaltenen Felder festgelegten Namenskonventionen folgen. Der Name einer CDS-View setzt sich dabei nach SAP-Empfehlung aus mehreren Bestandteilen zusammen:

Präfix: Gibt den View-Typ an (Beispiel: ”I_”: Basic-Interface-View oder Composite-Interface-View; “C_”: Consumption-View)
Semantischer Name gemäß Geschäftssemantik (Beispiel: „GoodsMovement“)
Suffix (optional): Schafft Klarheit über den Zweck der CDS-View (Beispiel: “Query”, “Cube” oder “Text”)
Versionsnummer (optional): Falls Views fortlaufend weiterentwickelt werden, kann so eine explizite Versionierung erfolgen

Auch bei den Feldnamen innerhalb der CDS-Views ist eine Orientierung an der Geschäftssemantik sinnvoll, um den Verwendungszweck offen zu legen. Gemäß der SAP-Empfehlung werden Feldnamen in drei Benennungselemente unterteilt:

Objekt: Stellt eine Objektklasse innerhalb der Geschäftssemantik dar (Beispiel: „SalesOrder“)
Eigenschaft: Ein Merkmal der Instanzen der Objektklasse (Beispiel: „Product“ innerhalb eines Auftrags)
Representation-Term: Spezifizierung des Datentyps der Eigenschaft (Beispiel: „Quantity“, „Amount“ oder „Date“)

Aus diesen Elementen kann beispielsweise der Feldname „SalesOrderProductQuantity“ zusammengesetzt werden.

Die richtige View finden – SAP Tools im Überblick

Wie das VDM aufgebaut ist und die analytischen Anwendungen mit Daten versorgt, ist nun klar. Wie kann ein Key-User allerdings eine spezifische View finden, um daraus möglicherweise eine neue View abzuleiten oder diese innerhalb einer analytischen Anwendung zu verwenden? SAP stellt dafür mehrere Fiori-Apps bereit: Den View Browser und den Query Browser. Zusätzlich ist es IT-Usern auch möglich, Views in den ABAP Development Tools zu untersuchen.

View Browser

Mithilfe des View Browsers können Key-User sämtliche Views innerhalb des VDM – angefangen bei den Basic-Interface-Views bis nach ganz oben zu den Consumption-Views – suchen und inspizieren. Mithilfe von Filtern kann auf Grundlage mehrerer Kriterien nach Views gesucht werden. Darunter unter anderem der Name, die Beschreibung, die Datenkategorie, Feldnamen sowie die Annotationen. Das Anlegen benutzerdefinierter Tags und die Funktion, Views als Favoriten abzuspeichern, ermöglichen es den Key-Usern, die für sie relevanten Views schnell und praktisch notieren zu können.

Für Views mit der Datenkategorie „Query“ steht im View Browser zudem eine Datenvorschau zur Verfügung. Darüber hinaus kann für Views der Datenkategorie „Cube“ direkt aus dem View Browser heraus eine analytische Query angelegt werden.

Query Browser

Neben dem View Browser existiert zusätzlich der Query Browser. Der Query Browser ist jedoch weitaus weniger technisch und bietet daher weniger Informationen. Der Query Browser kann im Vergleich zum View Browser nur Consumption-Views der Kategorie „Query“ anzeigen.

Eigene CDS Views erstellen – Standard erweitern, BI-Funktionalität stärken

Die Erstellung eigener Views auf Basis der von SAP bereitgestellten CDS-Views kann aus mehreren Gründen sinnvoll sein. Wenn die zugrundeliegenden Datenbanktabellen beispielsweise um kundenspezifische Felder erweitert wurden, können eigene CDS-Views Abhilfe schaffen, um diese neuen Felder aufzunehmen, die in den Standard-CDS-Views nicht berücksichtigt werden. Eigene CDS-Views ermöglichen zudem eine Simplifizierung von Standard-CDS-Views, um nicht-technischen Anwendern, die Queries definieren sollen, CDS-Views zur Verfügung zu stellen, die nur so komplex wie nötig sind und dabei möglicherweise verwirrende Details auslassen. Weitere realistische Szenarien sind zudem die Berechnung kundenspezifischer Geschäftslogik mithilfe berechneter Felder oder die Anwendung von Filtern, um CDS-Views für einen spezifischen Anwendungsfall zu erstellen.

Darstellung der Struktur einer benutzerdefinierten CDS-View in SAP S/4HANA. Die Grafik zeigt, wie Daten aus verschiedenen Basic- und Composite-Interface-Views aggregiert und durch Auswahlfelder sowie berechnete Felder zu einer benutzerdefinierten CDS-View kombiniert werden. Die Basis bilden Datenbanktabellen, auf die schrittweise aufgebaut wird. — Abbildung 2 -Benutzerdefinierte CDS-View im VDM

SAP ermöglicht die Erstellung von eigenen CDS-Views auf zwei unterschiedlichen Wegen: Key-User können mithilfe der „Custom CDS Views“ Fiori-App anhand eines geführten Prozesses step-by-step eine CDS-View erstellen ohne tiefgründiges technisches Wissen zu besitzen. Für Anwender mit einem technischen Hintergrund gibt es aber darüber hinaus die Möglichkeit, in den ABAP Development Tools der Eclipse IDE CDS-Views zu erstellen.

Die „Custom CDS Views“-App ermöglicht den Key-Usern die grafische Definition der gewünschten Quellen, Join-Bedingungen, Felder und Feldbezeichnungen, Berechnungen, Filter und Parameter ohne dabei ABAP CDS-Quellcode und OpenSQL-Syntax verwenden zu müssen. Ein klarer Fokus der App ist die Usability für Key-User. Damit geht jedoch auch einher, dass nicht der volle Modellierungsumfang für CDS-Views abgebildet werden kann. Zwar ist die „Custom CDS Views“-App in den meisten Szenarien ausreichend, in anderen Fällen müssen hingegen die ABAP Development Tools zur Modellierung verwendet werden, da dort der volle Funktionsumfang der ABAP CDS Modellierungssprache eingesetzt werden kann.

Fazit: CDS-Views & VDM – Fundament jeder BI-Strategie in SAP S/4HANA

Das Virtual Data Model (VDM) ist das Herzstück von SAP S/4HANA Embedded Analytics und damit auch eine Schlüsselkomponente jeder SAP-basierten Business Intelligence-Strategie. Durch die strukturierte Modellierung mit CDS Views können Unternehmen operative Daten performant und semantisch konsistent für Analysezwecke aufbereiten – direkt im S/4HANA System.

Ob mit Fiori-Apps für Key User oder den ABAP Development Tools für Entwickler – SAP bietet umfassende Werkzeuge zur Umsetzung individueller Analytics-Anforderungen.

Wenn Sie sich für operative BI mit SAP S/4HANA interessieren, lesen Sie auch unseren Beitrag:
„SAP BW/4HANA vs. SAP S/4HANA Embedded Analytics – Was brauchen Banken wirklich?“

Über den Autor

Jeremy Büdinger

Jeremy Büdinger ist Consultant bei der movisco AG im Bereich Data Warehousing & Analytics in Bonn. Er besitzt einen B.Sc. in Computerlinguistik mit Nebenfach Informatik. Seine Expertise beinhaltet Umsetzung von Berichtsanforderungen in SAP BW/4HANA und SAP BW on HANA, sowie Back-End-Implementierungen mit ABAP. Darüber hinaus verfügt Jeremy Büdinger über erste Erfahrungen im Bereich Requirements Engineering und im Projektmanagement.