Inhalt
Einleitung: Was ist SAP S/4HANA Embedded Analytics?
Embedded Analytics in SAP S/4HANA bezeichnet die direkte Integration analytischer Funktionen in dem operativen ERP-System. Im Gegensatz zu klassischen BI-Architekturen erfolgt die Analyse auf Live-Daten ohne Datenreplikation oder separates Data Warehouse wie z. B. einem SAP Business Warehouse.
Die technische Basis bildet das Virtual Data Model (VDM), das auf Core Data Services (CDS) und deren Views basiert. Diese CDS Views strukturieren Daten in mehreren Schichten und definieren sowohl semantische Logik als auch analytische Eigenschaften. Über Annotationen werden Funktionen wie Kennzahlen, Filter oder Aggregationen direkt im Datenmodell beschrieben. Dadurch entsteht eine konsistente und wiederverwendbare Datenbasis.
Konsumiert werden die Daten z. B. Im FIORI Launchpad als Smart Business KPIs, Multidimensionale Reports oder Analytical List Pages.
Bewährte Best Practices in Embedded Analytics
Modellierungsempfehlungen bei CDS Views
Best Practices in Embedded Analytics lassen sich zu einem konsistenten Bild zusammenführen, wenn man alle Ebenen – Modellierung, Annotationen, Governance – als zusammenhängendes System begreift statt als isolierte Einzelregeln.
Ausgangspunkt ist die konsequente Einhaltung der VDM-Schichtung:
Basic-Views greifen als einzige direkt auf Datenbanktabellen zu, selektieren ungefiltert und ohne Joins.
Composite-Views bauen ausschließlich auf Basic- und anderen Composite-Views auf. Consumption-Views konsumieren nur die Wiederverwendungsschicht.
Wer diese Trennung durchbricht, etwa durch direkten Tabellenzugriff in höheren Schichten oder durch Business-Logik in Composite-Views, die eigentlich reine Wiederverwendungsbausteine sein sollten, erkauft sich kurzfristige Bequemlichkeit mit Release-Instabilität, Performancebeeinträchtigungen und schlechter Wiederverwendbarkeit.
Für Verknüpfungen zwischen Views gilt durchgängig:
Associations statt Joins, weil Associations nur aufgelöst werden, wenn ein Feld tatsächlich angefragt wird, während Joins immer ausgeführt werden. Das ist der wirksamste Hebel gegen unnötige Laufzeitlast in Embedded-Analytics-Szenarien mit vielen konsumierenden Frontends und ein technisch sehr wirkungsvoller Vorteil gegenüber klassischen SQL-/BI-Datenmodellen. So kann bereits in der Datengrundlage (Composite-Views) ein breites Spektrum von Use Cases abgedeckt werden, die je nach Bedarf verschiedene Abfragen erzeugen.
Bei Annotationen zahlt sich eine bewusste Trennung nach Kategorie aus. Inhaltlich-semantische Annotationen – Währungsreferenzen, Mengeneinheiten, Feldlabels – gehören an ihre jeweilige Definitionsstelle und propagieren von dort automatisch durch den View-Stack. Sie in jeder Schicht zu wiederholen, erzeugt nur Divergenzrisiko (Vergabe einer Definition in Basic-View und in Consumption-View), wenn spätere Korrekturen nicht überall nachgezogen werden.
Eine Anpassung in der Definitionsstelle (Basic-View) würde sich daher nur bis zur Consumption-View durchsetzen, weil hier dasselbe Feld erneut (und redundant) definiert wird. Eine Änderung würde sich in diesem Fall nicht konsistent im Reporting niederschlagen und fällt erst dann auf, wenn Front-End User eine inkonsistente Beschriftung melden.
Strukturelle und rollenbeschreibende Annotationen dagegen, sowie Exposure-Annotationen müssen pro View explizit gesetzt werden, weil sie die eigenständige Rolle genau dieser View im Modell beschreiben und sich nicht sinnvoll vererben lassen.
Wichtig:
Sobald ein Feld umbenannt, aggregiert oder transformiert wird, bricht die Vererbungskette, und die Semantik muss an der neuen Stelle erneut gesetzt werden, eine häufig übersehene Fehlerquelle bei Aktivierungsproblemen.
Governance sollte so tief wie möglich im Stack verankert werden:
Die Zugriffsprüfung sollte auf Basic-View-Ebene, nahe an der Datenquelle stattfinden, statt sie auf jeder Consumption-View neu zu erfinden. Gleichzeitig empfiehlt es sich, die Berechtigungsprüfungs-Annotation dennoch explizit auf jeder Ebene zu deklarieren. Nicht, weil die Vererbung fehlt, sondern aus Transparenzgründen.
Damit ist beim Blick auf eine einzelne View sofort erkennbar, dass und wie geprüft wird.
Für die Erweiterung von Standardinhalten gilt:
Nicht die Original-Views modifizieren, sondern Metadatenerweiterungen für zusätzliche Annotationen und eigene Extension-Views für zusätzliche Felder nutzen. Das erhält die Update-Fähigkeit bei Release-Wechseln.
Und schließlich lohnt sich der Blick ins Tooling statt ins Gedächtnis:
Die „Active Annotations“-Ansicht in den ABAP Development Tools (ADT) zeigt für jede View und jedes Feld die tatsächlich wirksamen Annotationen samt Herkunft. Das ersetzt manuelle Dokumentation durch Nachvollziehbarkeit im System selbst und ist damit der praktikabelste Weg, Modell und Governance auch bei wachsender Komplexität konsistent zu halten.
Gestaltungsempfehlungen bei Reports im FIORI Launchpad
Bei Embedded Analytics basiert jeder gestaltbare Report auf einem Floorplan. Dieser legt grundlegende Design-Elemente fest, zum Beispiel die Position von Filtern und Diagrammen.
Wie ein Diagramm ausgeprägt wird (z. B. Balken- oder Liniendiagramm) ist dabei frei wählbar. Es ergibt daher Sinn für gleiche Zwecke gleiche Diagrammtypen zu verwenden und z. B. bei zeitlichen Verläufen nicht zwischen Linien- und Säulendiagramm zu wechseln, außer es soll auch ein Vergleich dargestellt werden.
Neben der Lesbarkeit beeinflusst die Wahl des Diagrammtyps auch die Performance eines Berichts. Besonders die Kategorie „Andere“ oder „Sonstige“ in Kreis- und Donut-Diagrammen kann dabei ungünstig sein. In dieser Kategorie werden alle Werte zusammengefasst, die keinen eigenen Anteil im Diagramm darstellen. Wird gezielt nach „Andere“ oder „Sonstige“ gefiltert, müssen die enthaltenen Einzelwerte wieder aufgelöst werden. Das kann zu einem vergleichsweise hohen Rechenaufwand führen und die Performance des Berichts beeinträchtigen.
Neben der Auswahl des passenden Diagrammtyps sind auch einheitliche Farben, Namenskonventionen und Kennzahlendefinitionen wichtig.
Dabei gilt: Die gleiche Farbe steht immer für den gleichen Zweck, zum Beispiel Grau für das Vorjahr und eine Schraffur für den Forecast. Auch Kennzahlen sollten einheitlich definiert und verwendet werden.
Gestaltungsrichtlinien gehören zu den wichtigsten Embedded Analytics Best Practices. Sie schaffen einheitliche Standards, erhöhen die Akzeptanz und sorgen dafür, dass insbesondere neue Berichte schnell verständlich und lesbar sind.
Whitepaper "SAP BW, SAP Datasphere und Embedded Analytics im Vergleich"
Welches SAP BI-Tool passt wirklich zu Ihrer Reportingstrategie? Dieses Whitepaper zeigt Ihnen, wie Sie Ihre SAP-Reportinglandschaft mit verschiedenen Ansätzen zukunftssicher aufstellen.
Download
Fallstricke in Embedded Analytics vermeiden
Klare Vergabe von Annotationen
Wie in den Best Practices in Embedded Analytics bereits kurz beschrieben, ist der Zweck einer CDS View nicht immer sofort erkennbar, denn was eine View „kann“ hängt teilweise davon ab, was das Konstrukt liefert, auf dem sie fußt. Ob eine View z. B. für Reporting oder Datenkonsum freigegeben ist, oder nicht, kann nur bewertet werden, wenn man ihre Annotationen kennt.
Es ergibt daher Sinn, bei der Modellierung einer CDS View immer jene strukturellen und rollenbeschreibenden Annotationen zu vergeben, die später benötigt werden, unabhängig davon, ob die View diese Eigenschaften bereits von ihrer Quelle geerbt hat, oder nicht. Ohnehin können nicht alle Annotationen sauber vererbt werden. Das spart sowohl Aufwand für Recherche im VDM und bietet gleichzeitig die Möglichkeit, einen standardisierten Header einzubinden, wie man ihn schon aus der Programmierung kennt.
Das Vorgehen birgt folglich das Risiko einer langen Liste von Annotationen. Es ist daher einzelfallabhängig abzuwägen, welche Annotation unkritisch und nicht-störend für den Gebrauch über mehrere Schichten hinweg ist, und welche einen Mehrwert durch vereinfachte Interpretierbarkeit liefert. Auf erstere kann demnach verzichtet werden.
Nicht betroffen davon sind semantische Annotationen, die konkrete Felder und deren Inhalt beschreiben, wie z. B. Kennzahlen-, Währungs- oder sonstige Definitionen. In der Regel ändern sich diese Eigenschaften nicht, einmal festgelegt kann auf die Wiederholung von Annotationen verzichtet werden.
Wartbare Zugriffssteuerung per DCL
Rollen und Berechtigungen sind auch im Kontext Embedded Analytics vorhanden, dort wird die Zugriffssteuerung auf Daten per Data Control Language (DCL) definiert. Hierfür spielen im Wesentlichen drei Komponenten zusammen:
- Die CDS View muss so annotiert werden, dass in ihr auf Berechtigung geprüft wird.
- Es muss ein Access Control-Objekt (AC-Objekt) vorhanden sein. Dieses verbindet die CDS View mit den technischen Berechtigungen aus dem PFCG-Objekt. Ein AC-Objekt kann in mehreren CDS Views verwendet werden.
- Eine PFCG-Rolle muss vorhanden sein, in der den Usern die Werte zugewiesen werden, für die sie berechtigt sind.
Das initiale Setup kann daher etwas Zeit in Anspruch nehmen, lässt sich aber durch die Wiederverwendbarkeit der AC-Objekte skalieren.
Wichtig hierbei:
Bei einem Join mehrerer auf Berechtigung geprüfter CDS Views werden auch die AC-Objekte behandelt. Die Ergebnismenge entspricht dabei der Schnittmenge der Daten der jeweils einzelnen CDS Views, auf die der User Zugriff hat.
Nicht zu vernachlässigen ist bei Berechtigungen der Aspekt der Vererbung. Da Berechtigungen vererbt werden, sollten diese so tief wie möglich modelliert werden. Wo möglich, also direkt nach der Datenbank-Schicht in der CDS Basic-Interface View-Schicht.
Fazit
SAP Embedded Analytics macht möglich, was klassische BI-Architekturen oft nur mühsam erreichen:
Die Analyse erfolgt in Echtzeit und direkt im operativen System, ohne Umweg über eine Replikation oder ein separates Data Warehouse. Möglich macht dies das VDM. Über CDS Views stellt es eine mehrschichtige und semantisch angereicherte Datenbasis bereit. Diese kann im FIORI Launchpad beispielsweise als Smart Business KPIs, multidimensionale Reports oder Analytical List Pages genutzt werden.
Damit dieses Potenzial nicht verpufft, zählt vor allem eines: Disziplin von Anfang an.
Die VDM-Schichtung, Basic-Views nah an der Datenbank, Composite-Views als Wiederverwendungsschicht, Consumption-Views für das Frontend. Diese Struktur ist kein bürokratisches Korsett, sondern der eigentliche Erfolgsfaktor. Wer sie durchbricht, erkauft sich heute ein paar Minuten und zahlt morgen mit Release-Instabilität und Performanceproblemen.
Genauso entscheidend: konsequent Assoziationen statt Joins einsetzen. Der Unterschied wirkt unscheinbar, entfaltet aber genau dort seine Wirkung, wo es zählt, in Szenarien mit vielen gleichzeitig zugreifenden Front Ends, wo unnötige Laufzeitlast sich sofort in spürbarer Trägheit niederschlägt. Besonders im operativen System, in dem User auch für das Tagesgeschäft arbeiten, muss dies so gut es geht vermieden werden. Zwei Dinge verdienen dabei besondere Aufmerksamkeit.
Erstens: Annotationen von Anfang an bewusst und vollständig setzen, nicht erst dann, wenn sie gebraucht werden. Gerade weil die Vererbungskette bei jeder Umbenennung, Aggregation oder Transformation eines Feldes abreißt, rächt sich Nachlässigkeit hier besonders schmerzhaft und meist erst spät, wenn User inkonsistente Beschriftungen melden. Wer stattdessen von Beginn an sauber modelliert, erspart sich mühsame Fehlersuche bei Aktivierungsproblemen.
Zweitens: Governance so tief wie möglich verankern, die Zugriffsprüfung gehört auf Basic-View-Ebene und nicht mehrfach neu modelliert auf jeder Consumption-View. Das ist nicht nur sauberer, sondern auch der einzige Weg, Berechtigungskonzepte wirklich skalierbar zu halten.
Auch beim Reporting selbst gilt: Konsistenz schlägt Beliebigkeit. Gleiche Diagrammtypen für gleiche Zwecke, kein Wechsel zwischen Linien- und Säulendiagramm bei Zeitverläufen, durchdachte Farbvergabe und einheitliche Kennzahlendefinitionen, all das entscheidet darüber, ob ein Bericht auf Anhieb verstanden wird oder Rückfragen produziert. Und wer sich unsicher ist, was eine CDS View eigentlich leistet: Ein Blick in die „Active Annotations“-Ansicht der ABAP Development Tools ersetzt zuverlässig jedes Rätselraten aus dem Gedächtnis.
Am Ende ist es genau diese Haltung, die den Unterschied macht: Embedded Analytics belohnt, wer von der ersten Modellierungsentscheidung bis zur letzten Diagrammfarbe konsequent bleibt, und bestraft jeden Kompromiss, der aus Bequemlichkeit gemacht wird.
Kontaktieren Sie uns!
Haben Sie weitere Fragen? Gerne helfen wir Ihnen weiter!
Vereinbaren Sie ein Webmeeting mit unseren Expert:innen oder stellen Sie uns Ihre Frage im Kommentarbereich.
Sie sehen gerade einen Platzhalterinhalt von Active Campaign. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen
