In Teil 1 unserer Blogbeitragsserie wurde der Einstieg in die Welt des S/4HANA Embedded Analytics vorgestellt. Dazu wurden die Grundlagen der Virtuellen Datenmodelle (kurz: VDM) und Core Data Services (kurz: CDS Views) erklärt. Außerdem wurde der erste Schritt unseres End-To-End-Vorgehensmodells anhand eines Beispiels gezeigt: die Identifikation existierender SAP Standard Views, die unmittelbar als Consumption View (im Folgenden häufig auch als Analytische Query oder kurz Query bezeichnet) für Ihr Reporting nutzbar sind.
Im zweiten Teil der Blogbeitragsserie zu S/4HANA Embedded Analytics schauen wir auf die Schritte 2–4 des End-To-End Prozesses, welche sich mit der Anpassung und Erweiterung von VDMs und mit Eigenentwicklungen im Kontext der CDS Views befassen:
End-to-End Prozess: Embedded Analytics Reporting
Neben den zahlreichen analytischen Apps und analytischen Queries, die SAP im Standard mit S/4HANA ausliefert, gibt es immer wieder Anforderungen an Queries und VDMs mit kundeneigener Logik. Wie man dabei idealerweise vorgeht, eigene Anpassungen durchführt und wie eigene VDMs erstellt werden können, wird im Folgenden anhand eines konkreten Beispiels erläutert. (Schritte 2 – 4)
Zur besseren Einordnung werden zunächst nochmal die Schritte „0. Anforderungen an Embedded Analytics Reporting“ und „1. Suche, Identifikation & Analyse bestehender VDMs bzw. CDS Views“ aufgegriffen, die in Teil 1 der Blogbeitrag-Serie bereits genauer thematisiert wurden.
0. Anforderung an Embedded Analytics Reporting
In unserem Szenario wird eine Query für Kundenauftragsköpfe und -positionen benötigt, welche später durch den End-User in verschiedenen Frontend-Tools genutzt werden soll.
1. Suche, Identifikation & Analyse bestehender VDMs bzw. CDS Views
In Teil 1 unserer Blogbeitragsserie haben wir bereits gezeigt, dass es Standard Consumption Views in diesem Bereich gibt und welche Apps bei der Suche unterstützen können.
Beim Testen der gefundenen Query C_SalesOrderItemQry für unser Szenario wurde jedoch festgestellt, dass
- nur Belege vom Typ „Aufträge“ (VBTYP = „C“) angezeigt werden. Entsprechend der festgelegten Anforderungen sollen allerdings uneingeschränkt sämtliche Belegtypen der Datenbanktabellen VBAK (Verkaufsbeleg: Kopfdaten) und VBAP (Verkaufsbeleg: Positionsdaten) analysiert werden. Bei der Analyse des VDMs stellt sich heraus, dass die Filterung bereits im darunterliegenden Composite View (im Folgenden häufig auch als Analytischer Cube oder kurz Cube bezeichnet) erfolgt (Anforderung 1).
- das Feld „Angelegt am“ des Auftragskopfes lediglich als Anzeigeattribut der Dimension „Auftrag“ vorhanden ist. Das Feld soll vielmehr als eigene Dimension im Reporting zur Verfügung stehen, um flexibel danach navigieren und auswerten zu können (Anforderung 2).
Anmerkung: Es gibt ein Feld „Angelegt am“ im Standard View. Dieses bezieht sich allerdings auf die Positionen, nicht auf den Kopf des Kundenauftrags.
2. Custom VDM Views: Erstellung eigener CDS Views
In unserem Szenario liefert der Standard Composite View I_SalesOrderItemCube ein eingeschränktes Datenset – nämlich nur Belege vom Typ „Aufträge“. Somit beschränken sich die Anpassungen nicht nur auf den Consumption View, sondern auch auf den darunterliegenden Composite View.
Die folgende Abbildung zeigt einen Ausschnitt des Virtuellen Datenmodells und einen Überblick über die anzulegenden Objekte:
Im ersten Schritt soll ein neuer Analytischer Cube entwickelt werden, um die Filterung auf den Belegtyp aufzuheben und das Anlegedatum des Auftragskopfes hinzuzufügen. Im zweiten Schritt soll dann die Analytische Query erstellt werden.
Es gibt grundsätzlich zwei Möglichkeiten, eigene, benutzerdefinierte CDS Views zu erstellen:
- Custom VDM Views – Fiori App: Benutzerdefinierte CDS-Views
- Custom VDM Views – ABAP Development Tools (empfohlen)
Zu a) Custom VDM Views – Fiori App: Benutzerdefinierte CDS-Views
Mit der Fiori App „Benutzerdefinierte CDS-Views“ (EN: „Custom CDS Views“) können IT-affine Power User auf graphischer Benutzeroberfläche eigene CDS Views neu erstellen oder bestehende, benutzerdefinierte CDS Views kopieren und anpassen.
Dabei wird der User anhand eines Workflows durch die Erstellung geleitet:
Im ersten Schritt wird der User aufgefordert, eine primäre Datenquelle auszuwählen. Hierbei werden bereits erste Einschränkungen der App im Vergleich zur Entwicklung mit den ABAP Development Tools deutlich:
- Einschränkung 1: Standard CDS Views der SAP können nicht kopiert werden.
- Einschränkung 2: Es können nur Views als Datenquelle oder Assoziation verwendet werden, die den Status „Freigegeben“ haben.
- Einschränkung 3: Es können keine Datenbanktabellen als Datenquelle oder Assoziation genutzt werden.
Exkurs: Freigabe-Status
Standard CDS Views können von der SAP freigegeben werden. Ziel ist es, Eigenentwicklungen auf der Grundlage dieser Views zu ermöglichen und eine ausreichende Stabilität zu gewährleisten, damit diese Entwicklungen auch nach einem System-Upgrade noch funktionieren.
Auch kundenspezifische Eigenentwicklungen können freigegeben werden und stehen damit in Key-User-Apps zur Verfügung.
Der Standard Cube I_SalesOrderItemCube der SAP ist freigegeben. Entwicklungen auf dessen Grundlage sind möglich. Da wir diesen nachbilden und dann leicht anpassen müssen (Belegtyp-Filter entfernen) und nicht kopieren können (Einschränkung 1), müsste dieser mit der Fiori App aufwendig nachgebaut werden.
Als primäre Datenquelle wird dann idealerweise der View verwendet, aus dem auch der I_SalesOrderItemCube selektiert, da dieser bereits einige Business und semantische Logiken enthält: I_SalesDocumentItemAnalytics.
Der Composite View I_SalesDocumentItemAnalytics ist allerdings nicht freigegeben und kann damit nicht als Datenquelle genutzt werden (Einschränkung 2). Der SAP Standard View muss nachgebaut werden, oder – entgegen der SAP – vom Kunden freigegeben werden. Aber auch nach Freigabe wird der Nachbau des Analytischen Cubes mit all seinen Assoziationen und Business Logiken aufwendig. Auch auf die Basisdaten aus den Datenbanktabellen kann nicht zugegriffen werden (Einschränkung 3).
Aufgrund der Einschränkungen und dem höheren Aufwand beim Nachbilden des Cubes wird dieser Ansatz hier nicht weiterverfolgt.
Zu b) Custom VDM Views – ABAP Development Tools (empfohlen)
Einfacher und mit deutlich weniger Einschränkungen konfrontiert ist ein Entwickler bei der Erstellung von CDS Views mit den ABAP Development Tools in Eclipse.
Dazu muss zunächst ein ABAP Projekt für das S/4HANA System in Eclipse erstellt werden. Nach erfolgreicher Anlage und Login lassen sich in der System Library sämtliche ABAP Objekte, strukturiert nach ABAP Paketen, finden. Die CDS Views für Kundenaufträge befinden sich im Paket VDM_SD_ANALYTICS.
Wie bereits erwähnt, wollen wir den Quelltext des I_SalesOrderItemCube kopieren – um bestehende Business Logiken und Semantik zu verwenden – und einen neuen Analytischen Cube anlegen. Der Vorteil hierbei ist, es muss kein neues VDM oder ein neuer CDS View von Grund auf erstellt werden, wie es unter Umständen in der Fiori App „Benutzerdefinierte CDS-Views“ nötig wäre.
Im ABAP Paket VDM_SD_ANALYTICS oder über die ABAP Objekt-Suche wird zunächst nach dem View I_SalesOrderItemCube gesucht und das Objekt per Doppelklick geöffnet. Der Quelltext wird anschließend in die Zwischenablage kopiert.
Ein neuer CDS View kann per Rechtsklick auf einem passenden ABAP Paket (in unserem Fall ZSD für Eigenentwicklungen im SD Umfeld) erstellt werden: ZSD > New > Other ABAP Repository Object > Core Data Services > Data Definition > … .
Der technische Name unseres neuen CDS Views lautet ZSD_SalesOrderItemCube (Beschreibung: Sales Order Item – Cube (Custom)). Als Template kann “Define View Entity” verwendet werden.
Nach der Erstellung kann der aus dem Template generierte Code gegen den kopierten Quelltext des Standard Views ausgetauscht und angepasst werden. Anstatt einem klassischen DDIC-basierten View (“Define View…”) wird eine modernere CDS View Entität (“Define View Entity…”) erstellt. Wichtig hierbei ist, dass der Name hinter „Define View Entity…“ dem CDS View (Data Definition) Namen entspricht (hier: ZSD_SalesOrderItemCube). Mit der modernen CDS View Entität entfallen einige Annotationen, die einfach entfernt oder auskommentiert werden können wie z. B.:
// @AbapCatalog: {
// sqlViewName: 'ISDSALESORDERIC',
// compiler.compareFilter: true,
// preserveKey: true
// }
…
define view entity ZSD_SalesOrderItemCube
with parameters
...
as select from I_SalesDocumentItemAnalytics
...Zu Anforderung 1: Eine Anforderung ist es, dass sämtliche Belegtypen mit der Query analysiert werden können. Dazu muss der Filter auf den Vertriebsbelegtyp (SDDocumentCategory) entfernt werden. Am Ende des Codes wird die „Where“-Bedingung, die für diese Filterung verantwortlich ist, auskommentiert:
// where
// SDDocumentCategory = 'C';Zu Anforderung 2: Außerdem soll das Feld „Angelegt am“ des Auftragskopfes als eigene Dimension bereitgestellt werden. Im Dimension View I_SalesOrder existiert zwar das Anlegedatum als Feld, ist dadurch jedoch nur Anzeigeattribut des Auftrags. Daher wird im neuen Composite View das Feld CreationDateSalesOrder über die Assoziation _SalesOrder am Ende der Feldliste (vor der geschweiften Klammer) hinzugefügt.
…
_SalesOrder.CreationDate as CreationDateSalesOrder
}
Tipp: Über STRG + SPACE erhält man Coding-Hilfe und kann so das richtige Feld der passenden Assoziation auswählen.3. Custom Analytical Queries: Erstellung eigener Consumption Views
Nachdem der kundeneigene, analytische Cube erfolgreich erstellt und aktiviert wurde, kann jetzt mit der Anlage der Query begonnen werden. Auch hier gibt es grundsätzlich zwei Möglichkeiten.
- Custom Analytical Queries – Fiori App: Benutzerdefinierte analytische Abfragen (empfohlen)
- Custom Analytical Queries – ABAP Development Tools (empfohlen)
Zu a) Custom Analytical Queries – Fiori App: Benutzerdefinierte analytische Abfragen (empfohlen)
Mit der Fiori App „Benutzerdefinierte analytische Abfragen“ (EN: Custom Analytical Queries) können Business User graphisch eigene Queries auf Basis eines Analytischen Cubes neu erstellen oder (sowohl Standard als auch benutzerdefinierte) Queries kopieren und anpassen. Ein Austausch der Datenquelle ist nach der Kopie nicht möglich.
In unserem Szenario soll deshalb eine neue Analytische Query auf Basis des erstellten Cube ZSD_SalesOrderItemCube angelegt werden. Um den benutzerdefinierten Cube als Datenquelle nutzen zu können, muss dieser zunächst (für Key-User-Apps) freigegeben werden. Die Freigabe eclipse-basierter Views erfolgt in der Entwickleroberfläche entweder unter den Properties oder per Rechtsklick auf dem CDS View im Project Explorer und dann API State > (Add) Use System-Internally (Contract C1) > Release State: Release > Flag: Use in Key User Apps > Next > … .
Sobald der CDS View freigegeben ist, steht dieser als Datenquelle in der Fiori App Custom Analytical Query zur Verfügung. Auch beim Anlegen in dieser App wird man mittels eines Workflows durch den Erstellungsprozess geführt:
Zunächst werden allgemeine Query-Einstellungen festgelegt, wie beispielsweise die Beschreibung oder der Umgang mit Null-Werten. Anschließend können im nächsten Schritt unter „Feldauswahl“ die benötigten Merkmale und Dimensionen hinzugefügt werden. Zur Auswahl stehen alle Elemente, die im Analytischen Cube vorhanden sind, unter anderem auch das neu hinzugefügte Feld „Angelegt am“ (CreationDateSalesOrder):
Unter „Anzeigen“ können dann genauere Feld-Einstellungen festgelegt werden:
- Initialer Aufriss der Query für Zeilen & Spalten
- Einstellungen zur Anzeige von Dimensionen und Kennzahlen#
- Erstellung von eingeschränkten, berechneten und konvertierten Kennzahlen
- Hinzufügen von Zähler und Strukturelementen
Im letzten Prozessschritt können Filter und Parameter definiert werden. Hier muss in unserem Szenario nichts weiter angepasst werden.
Die App „Benutzerdefinierte analytische Abfragen“ eignet sich ideal zur Erstellung ganz neuer Queries (sowohl auf Standard als auch auf benutzerdefinierten Cubes) oder zur Kopie bestehender Queries, wenn deren Datenquelle nicht ausgetauscht werden muss. Diese ist intuitiv vom Business User zu bedienen.
Zu b) Custom Analytical Queries – ABAP Development Tools (empfohlen)
In unserem Szenario gibt es bereits einen Standard Consumption View C_SalesOrderItemQry. Dieser enthält bereits alle Merkmale und Kennzahlen sowie entsprechende Semantik, die für das Reporting relevant sind.
Anstatt die Analytische Query mit der Fiori App neu zu erstellen, kann der Quelltext der bestehenden Query über die ABAP Development Tools in Eclipse als Vorlage genutzt werden. Dazu wird analog zum Vorgehen beim Cube eine neue CDS View Entität ZSD_SalesOrderItemQry erstellt und anschließend der kopierte Quelltext der Standard Query eingefügt.
Der Entitäten Name nach „Define View Entity…“ wird dann wieder auf ZSD_SalesOrderItemQry geändert und die Datenquelle nach „as select from…“ ausgetauscht. Auch hier müssen wie schon im Cube einige Anpassungen gemacht werden, die mit der CDS View Entität einhergehen. Außerdem wird das neue Feld CreationDateSalesOrder (Anlegedatum des Kundenauftragkopfes) hinzugefügt.
// @AbapCatalog: {
// sqlViewName: 'ZSDSLSORDERITEMQ',
// compiler.compareFilter: true
// }
…
define view entity ZSD_SalesOrderItemQry
with parameters
…
as select from ZSD_SalesOrderItemCube …
{
…
CreationDateSalesOrder
}
Sobald alle Anpassungen abgeschlossen sind, muss der CDS View aktiviert und zur Nutzung freigegeben werden. Dabei ist zu beachten: Ein eigenes VDM mit benutzerdefinierten Queries sollte nicht ohne geeignetes Berechtigungskonzept implementiert werden.
Exkurs: (Analyse-)Berechtigungen eines VDMs:
Ein eigenes VDM mit benutzerdefinierten Queries sollte nicht ohne geeignetes Berechtigungskonzept implementiert werden. Ein User sollte nur den (Teil-)Datenbestand sehen dürfen, auf den er auch im S/4HANA berechtigt ist. Die Analyseberechtigungen in Embedded Analytics werden über sogenannte Data Access Controls (kurz: DAC) gesteuert.
DACs sind Core Data Services, die eine Data Control Language (kurz: DCL) verwenden, um die Daten bereits auf Cube-Ebene nutzerabhängig zu berechtigen. Die Berechtigungen für den analytischen Cube werden dann automatisch an alle Analytischen Queries vererbt, die darauf mit der Fiori App oder den ABAP Development Tools erstellt werden.
Es gibt verschiedene Arten von DACs, um Berechtigung zu steuern. Häufig werden Datenzugriffe über SAP Standard Berechtigungsobjekte und der entsprechenden Ausprägung des Users eingeschränkt.
Die SAP hat bereits einige DACs erstellt, um Standard VDMs zu berechtigen. An diesen kann sich auch beim Aufbau eigener Berechtigungen orientiert werden. DACs werden im SAP Standard wie der entsprechende Cube benannt, den sie berechtigen, hier: I_SalesOrderItemCube.
Um den neu erstellten Cube mit all seinen Queries zu berechtigen, wird eine eigene DAC mit Namen ZSD_SalesOrderItemCube analog zum Standard der SAP implementiert.
Dieser kann per Rechtsklick auf dem ABAP Paket ZSD/Core Data Services > New > Access Control erstellt werden:
Der SAP Standard View dient dabei als Vorlage. Die technischen Namen in der originären DAC werden entsprechend angepasst.
Die fertige, benutzerdefinierte DAC sehen Sie in der folgenden Abbildung:
Die DAC ZSD_SalesOrderItemCube schränkt den gleichnamigen Cube ZSD_SalesOrderItemCube über die SAP Standard Berechtigungsobjekte V_VBAK_AAT und V_VBAK_VKO ein. Ein User muss auf diese Objekte berechtigt sein. Je nach Ausprägungen innerhalb der Objekte sieht der User nur die ihm erlaubten Auftragsarten (AUART), Verkaufsorganisationen (VKORG), Vertriebswege (VTWEG) und Divisionen (SPART).
4. Reporting
Nach erfolgreichem Aktivieren des CDS Views kann dieser als analytische Query in den gängigen Frontend Tools genutzt werden.
Typische Reporting Anwendungen sind die SAP Analytics Cloud und Analysis for Office, in denen
- bei CDS DDIC-basierten Views (Define View) der SQL View Name und
- bei CDS Entitäten (Define View Entity) der Data Definition Name
mit dem Präfix 2C* als Datenquelle dient.
Innerhalb des S/4HANA gibt es verschiedene Berichtstypen, die zur Visualisierung der Daten dienen und als eigene Fiori Kacheln zur Verfügung gestellt werden:
- Das Multidimensionale Reporting innerhalb des Fiori Launchpads stellt eine einfache OLAP-Abfrage da, bei dem der End-User sich seine Tabelle oder Visualisierungen flexibel mit allen verfügbaren Merkmalen und Kennzahlen erstellen kann.
- Smart Business Apps dagegen sind Visualisierungen, die einem vorgefertigten Analysepfad folgen und die Daten nach vordefinierten Dimensionen und Filterungen. Diese können in der App KPI Modeler erstellt werden. Die Basis hierfür ist ein aktiver OData Service.
- Analytical Fiori Apps sind komplexere Entwicklungen mit Integration und Absprüngen zu verschiedensten Berichten. Die Basis sind auch hier CDS View vom Typ Analytical Queries und aktive OData Services.
Das war das Realtime Reporting mit kundeneigenen VDMs mit S/4HANA Embedded Analytics
Mit S/4HANA Embedded Analytics erhält der Business User die Möglichkeit mittels verschiedener Fiori Apps oder SAP Frontends seine Daten in Echtzeit zu analysieren. Dabei können viele Standard Reporting Apps und vorgefertigte VDM der SAP ohne zusätzliche Aufwände genutzt werden. Falls Anpassungsbedarf oder Anforderungen an kundeneigene VDM bestehen, können Entwickler diese mit den ABAP Development Tools implementieren.
Darauf aufbauend können eigene Reporting Apps erstellt und diese dem End-User über eine Kachel zur Verfügung gestellt werden. Daneben stehen dem Power User für die Entwicklung verschiedene Apps zu Verfügung, um eigene Queries und eigene Datenmodelle zu erstellen, wobei insbesondere die App “Custom Analytical Queries” zu empfehlen ist. Embedded Analytics ergänzt damit das bestehende Analytics Portfolio mit Reports und Anwendungen innerhalb des S/4HANA um Benutzer bei operativen Prozessen und täglichen Entscheidungen optimal zu unterstützen.
