Virtual Data Models mit SAP CDS: Ihr Co Pilot für Reporting und Analytics 

Stellen Sie sich vor, Sie sind der Pilot eines Flugzeugs (natürlich inspiriert vom SAP-Flugdatenmodell), und Ihre Instrumententafel liefert Ihnen unzählige Daten: Flughöhe, Geschwindigkeit, Treibstoffverbrauch, Passagierlisten – aber ohne klare Struktur wären Sie verloren. Genau hier helfen Virtual Data Models (VDM) mit SAP Core Data Services (CDS), die Ihre SAP-Daten in perfekt organisierte, performante und wiederverwendbare Analytics-Modelle verwandeln.

In diesem Artikel erklären wir detailliert, was VDMs sind, warum sie unverzichtbar für Reporting und Analytics in SAP sind, und zeigen Ihnen anhand eines umfassenden Beispiels mit dem SAP-Flugdatenmodell, wie Sie eigene CDS-Views entwickeln. Wir ergänzen dies mit Best Practices aus zahlreichen CloudDNA-Projekten und technischen Details, die Sie sofort in Ihren eigenen Projekten anwenden können.

Was sind Virtual Data Models?

VDMs sind semantische Schichten, die Datenstrukturen in SAP definieren, ohne diese physisch zu kopieren. Diese Schichten umfassen detaillierte Definitionen von Datenquellen, logische Verknüpfungen und semantische Anreicherungen. VDMs ermöglichen es, komplexe Reporting-Strukturen mit hoher Performance und Flexibilität aufzubauen. Sie bestehen typischerweise aus drei Ebenen, wobei jede Ebene ihre eigene Funktionalität und Detaillierung hat, die wir hier ausführlich erklären:

Interface Views

Rohdaten aus Tabellen, meist 1:1, wobei jedes Feld sorgfältig abgebildet wird, um eine performante und wartbare Datenbasis zu schaffen. Hier werden nicht nur die Tabellenfelder ausgewählt, sondern auch Datentypen, Schlüssel und mögliche Berechtigungen berücksichtigt. Zudem sind Interface Views oft mit wichtigen technischen Annotations versehen, um eine korrekte Integration in die gesamte VDM-Architektur sicherzustellen. Die Dokumentation dieser Views sollte detailliert sein, da sie die Grundlage für alle weiteren Ebenen bildet, was in komplexen Analytics-Szenarien von entscheidender Bedeutung ist.

Composite Views

Kombination mehrerer Interface Views mit Berechnungen, wobei hier nicht nur Tabellen zusammengeführt, sondern auch komplexe Berechnungen, Aggregationen und Transformationen durchgeführt werden. Diese Views dienen als logische Zwischenschicht, in der Business-Logik integriert werden kann, ohne die Rohdaten zu verändern. Sie enthalten häufig berechnete Felder, wie z.B. Kennzahlen (KPIs), Durchschnittswerte, Summen und andere aggregierte Daten. Zudem werden hier Joins oder Associations definiert, um Daten aus verschiedenen Interface Views zu kombinieren. In der Praxis sorgen Composite Views dafür, dass im Consumption View weniger Berechnungen durchgeführt werden müssen, was die Performance verbessert und die Wartbarkeit erhöht. Ein gutes Beispiel wäre ein Composite View, der Flugdaten, Ticketpreise und Flugpläne kombiniert und gleichzeitig die Auslastung und den Gesamtumsatz berechnet, wie im nachfolgenden Beispiel gezeigt wird.

Consumption Views

Endnutzer-freundliche Modelle für Dashboards und KPIs, die durch durchdachte Annotations wie @Analytics.dataCategory und @UI.lineItem für eine optimale Darstellung und Performance sorgen. In Consumption Views werden Aggregationen, Filter und Parameter für Endanwender implementiert. Sie bieten die Schnittstelle zu Reporting-Tools wie der SAP Analytics Cloud oder Fiori Analytical Apps. Ein Consumption View sollte nicht nur performant, sondern auch flexibel erweiterbar sein, um dynamische KPIs, Drilldowns und Ad-hoc-Analysen zu ermöglichen. Best Practices umfassen eine saubere Trennung der Business-Logik, eine detaillierte Dokumentation und den Einsatz von Berechtigungsprüfungen mittels CDS-Access Controls. Beispiele sind Dashboards zur Flugauslastung oder Revenue-Analysen, die alle notwendigen Daten für das Management liefern.

Diese Struktur stellt sicher, dass Ihre Analytics-Modelle flexibel, performant und leicht wartbar bleiben.

VDM-Architektur in SAP CDS: Detaillierte Schritt-für-Schritt-Erklärung

Interface View: Flugdatenbasis aus SFLIGHT

Hier beginnen wir mit einem Interface View, der die Rohdaten aus SFLIGHT liefert. Dieser Abschnitt wird erweitert, um detailliert die Struktur der SFLIGHT-Tabelle zu erklären, die Felder wie CARRID (Carrier ID), CONNID (Connection ID) und FLTDATE (Flugdatum) enthält. Außerdem werden die Bedeutungen der einzelnen Felder beschrieben, inklusive PAYMENTSUM (Gesamtumsatz), SEATSMAX (Maximale Sitzplätze) und SEATSOCC (Belegte Sitzplätze). Ebenso wird auf die Wichtigkeit der korrekten Datentypdefinitionen und Schlüssel eingegangen, um eine performante Abfrage sicherzustellen. Zudem erklären wir, wie Annotationen wie @EndUserText.label für eine bessere Benutzererfahrung sorgen. Eine saubere Trennung dieser Rohdaten ist essenziell für spätere Verknüpfungen mit anderen Views und eine effiziente Nutzung in Analytics-Szenarien. Somit wird dieser Interface View zur robusten Grundlage für alle weiteren Analysen und Berechnungen.

@AbapCatalog.sqlViewName: 'ZFLIGHTBASE'
@EndUserText.label: 'Flug-Basisdaten'
define view Z_I_Flight as select from SFLIGHT
{
    key CARRID,
    key CONNID,
    key FLTDATE,
    PAYMENTSUM,
    SEATSMAX,
    SEATSOCC
}

Interface View: Flugpläne aus SPFLI

Als Nächstes benötigen wir einen Interface View für Flugpläne. Hier erläutern wir detailliert die Struktur der SPFLI-Tabelle mit Feldern wie CARRID (Airline-Code), CONNID (Verbindungs-ID), AIRPFROM (Abflugort) und AIRPTO (Ankunftsort). Zusätzlich erklären wir die Bedeutung der Felder DISTANCE (Distanz zwischen den Flughäfen) und FLTYPE (Flugtyp, z.B. Inland oder international). Zudem werden wichtige Annotationen wie @EndUserText.label und @AbapCatalog.sqlViewName beschrieben, die für eine saubere Dokumentation und Integration sorgen. Dieser Interface View bildet die Grundlage für spätere Associations und Composite Views, was in Analytics-Szenarien entscheidend ist.

@AbapCatalog.sqlViewName: 'ZFLIGHTPLAN'
@EndUserText.label: 'Flugpläne'
define view Z_I_FlightPlan as select from SPFLI
{
    key CARRID,
    key CONNID,
    AIRPFROM,
    AIRPTO,
    DISTANCE,
    FLTYPE
}

Diese Views bilden die Grundlage und gewährleisten saubere, performante Datenstrukturen.

Composite View: Verknüpfung beider Interface Views mit Association

Der Composite View kombiniert beide Datenquellen und bildet das Herzstück der VDM-Architektur. Hier werden die Interface Views Z_I_Flight und Z_I_FlightPlan über eine Association verbunden. Associations sind in SAP CDS eine effiziente Alternative zu klassischen Joins, da sie nur dann geladen werden, wenn sie tatsächlich benötigt werden, was die Performance verbessert. In diesem Composite View wird nicht nur eine Verknüpfung erstellt, sondern auch eine Berechnung der Sitzplatz-Auslastung durchgeführt. Wir erläutern hier zusätzlich die Bedeutung der Association-Syntax, den Aufbau des On-Conditions, die verwendeten Feldzuweisungen und wie berechnete Felder direkt in einem CDS-View integriert werden. Außerdem wird erklärt, wie die korrekte Namensgebung und Annotationen wie @AbapCatalog.sqlViewName für die technische Implementierung essenziell sind. Dieser Abschnitt liefert ein tiefes technisches Verständnis für die Erstellung eines Composite Views und dessen Rolle im gesamten VDM-Framework.

@AbapCatalog.sqlViewName: 'ZFLIGHTCOMP'
@EndUserText.label: 'Flugdaten mit Flugplänen'
define view Z_C_FlightDetails as select from Z_I_Flight
	association [1..1] to Z_I_FlightPlan as _FlightPlan 
		on Z_I_Flight.CARRID = _FlightPlan.CARRID 
	 and Z_I_Flight.CONNID = _FlightPlan.CONNID
{
    key Z_I_Flight.CARRID,
    key Z_I_Flight.CONNID,
    key Z_I_Flight.FLTDATE,
    _FlightPlan.AIRPFROM,
    _FlightPlan.AIRPTO,
    Z_I_Flight.SEATSOCC / Z_I_Flight.SEATSMAX * 100 as OccupancyRate,
    case 
      when Z_I_Flight.SEATSOCC = Z_I_Flight.SEATSMAX then 'Ausgebucht' 
      else 'Verfügbar' 
    end as SeatStatus
}

Hier nutzen wir eine Association, um eine performante Verknüpfung zu erstellen.

Consumption View: Endnutzer-freundliches Analytics-Modell

Der Consumption View wird schließlich für Dashboards und Berichte verwendet. Hier erklären wir detailliert, wie ein Consumption View aufgebaut wird, welche Annotationen notwendig sind, wie Berechtigungen implementiert werden und wie dynamische Filter, Aggregationen und Berechnungen im View umgesetzt werden. Außerdem erläutern wir, wie dieser View in SAP Analytics Cloud oder Fiori Analytical Apps eingebunden wird, inklusive technischer Parameter, Best Practices für die Performance-Optimierung und Tipps zur Fehlersuche. Mit diesen zusätzlichen Details wird deutlich, wie ein leistungsstarker Consumption View erstellt wird, der flexibel, wartbar und für komplexe Reporting-Szenarien geeignet ist.

@AbapCatalog.sqlViewName: 'ZFLIGHTCONS'
@Analytics.dataCategory: #CUBE
@Analytics.query: true
@EndUserText.label: 'Fluganalyse für Analytics'
define view Z_Cons_FlightAnalytics as select from Z_C_FlightDetails
{
    key CARRID,
    key CONNID,
    FLTDATE,
    AIRPFROM,
    AIRPTO,
    OccupancyRate,
    SeatStatus,
    count(*) as FlightCount,
    sum(PAYMENTSUM) as TotalRevenue
}

Technische Details und Best Practices Virtual Data Models:

In diesem Abschnitt gehen wir noch tiefer ins Detail: Wir erklären umfassend die verschiedenen Annotations in SAP CDS, wie @AbapCatalog.sqlViewName, @EndUserText.label, @Analytics.dataCategory und @AccessControl, und warum sie essenziell für ein sauberes, performantes Reporting sind. Wir beschreiben Best Practices zur Optimierung von CDS-Views, wie die Verwendung von Associations für Lazy Loading, den Einsatz von Berechtigungen direkt in den Views und die Strukturierung von VDMs für Wiederverwendbarkeit. Außerdem beleuchten wir häufige Fallstricke bei der Modellierung, geben Tipps zur Performance-Analyse mit dem PlanViz-Tool und zeigen, wie CDS-Views für SAP Analytics Cloud und Fiori optimal vorbereitet werden. Zudem gehen wir auf konkrete Beispiele aus der Praxis ein, etwa wie wir bei CloudDNA für einen Kunden ein mehrstufiges VDM entwickelt haben, das in der SAP Analytics Cloud Echtzeit-KPIs liefert und gleichzeitig wartbar und flexibel bleibt. Schließlich erläutern wir, wie technische Dokumentation, Namenskonventionen und Teststrategien ein robustes CDS-Reporting sicherstellen.

  • Annotations nutzen: Wichtige Annotations wie @Analytics.dataCategory sind unerlässlich.
  • Performance-Optimierung: Verwenden Sie Associations anstelle klassischer JOINs.
  • Berechtigungen: Implementieren Sie @AccessControl direkt im View.

CloudDNA: Ihr Partner für SAP CDS-Reporting

Ob VDM-Architektur, Performance-Tuning oder SAP Analytics Cloud Integration – CloudDNA bringt Ihre Analytics-Projekte zum Abheben! Mit unserer umfangreichen Erfahrung in der SAP-Beratung, der Entwicklung komplexer CDS-Views und der Integration in Analytics-Tools bieten wir nicht nur technische Expertise, sondern auch maßgeschneiderte Lösungen für Ihre individuellen Anforderungen. Unser Team unterstützt Sie bei der Optimierung Ihrer CDS-Modelle, der Implementierung von Best Practices und der Erstellung leistungsstarker Dashboards. Wir begleiten Sie von der Analyse bis zum Go-Live und darüber hinaus, um sicherzustellen, dass Ihre Analytics-Projekte nicht nur starten, sondern auch erfolgreich durchstarten. Vertrauen Sie auf CloudDNA für präzise, performante und zukunftssichere SAP-Analytics-Lösungen.

Bleiben Sie dran für weitere Artikel mit noch mehr technischen Details, Best Practices und Praxisbeispielen.