1 Grundlagen von Embedded Analytics
In diesem Kapitel möchte ich Ihnen einen ersten Eindruck vom Konzept und von den technischen Grundlagen der Embedded Analytics von SAP vermitteln.
1.1 Was verbirgt sich hinter Embedded Analytics?
Ich könnte Ihnen vorab die Entstehungsgeschichte und wichtigsten Grundlagen von SAP S/4HANA erläutern, verzichte aber bewusst darauf, da es bereits sehr viel großartige Lektüre zu diesem Thema gibt. Fakt ist: Das volle Potenzial von Embedded Analytics können Sie nur mit SAP S/4HANA nutzen. Grund dafür ist u.a. die neue, vereinfachte Datenarchitektur in Verbindung mit der In-Memory-Datenbank SAP HANA. Letztere ermöglicht beispielsweise, sämtliche Informationen zu einem Beleg der Finanzbuchhaltung aus dem Universal Journal und damit aus der Tabelle ACDOCA (Accounting Document Actuals) zu erhalten. Das Universal Journal ist quasi ein InfoProvider.
Wir befinden uns mitten in der digitalen Transformation. Informationen werden immer kurzlebiger, müssen schnellstmöglich bereitgestellt werden und können ggf. entscheidende Wettbewerbsvorteile bedeuten. Sie sind das Gold der heutigen Zeit.
Genau hier setzt die neue Technologie der Embedded Analytics von SAP an. Im Gegensatz zum klassischen Business Warehouse, bei dem nur der Ansatz OnLine Analytical Processing (OLAP) verfolgt wird, werden mit Embedded Analytics die Ansätze OLAP und OnLine Transaction Processing (OLTP) kombiniert. OLTP ist der klassische Reporting-Ansatz (verwendet beispielsweise auch in SAP ERP Central Component, SAP ECC), bei dem operative Daten transaktional analysiert werden. Mit OLAP hingegen werden große Datenmengen mittels komplexer Datenstrukturen verdichtet und möglichst schnell ausgewertet. Allerdings dürfen wir hierbei nicht vergessen, dass die Daten zunächst aus einem operativen ERP-System extrahiert werden müssen. Hierbei von schnell oder wirklichem Realtime-Reporting zu sprechen, wäre falsch.
Mit Embedded Analytics ist es also möglich, die Daten in Echtzeit zu analysieren, da zuvor keine komplexen Datenstrukturen oder Programme zu durchlaufen sind, sondern die Daten direkt von der Datenbank abgerufen werden.
Dazu werden spezielle Objekte verwendet, die ich Ihnen im nächsten Abschnitt näher erläutern werde.
1.2 Die Systemarchitektur
Zunächst möchte ich Ihnen anhand von Abbildung 1.1 die Systemarchitektur eines SAP-S/4HANA-Systems erklären.
Abbildung 1.1: Systemlandschaft des Embedded Reporting in SAP S/4HANA
Die SAP-HANA-In-Memory-Datenbank bildet den Kern der Embedded Analytics, dem wiederum ein relationales Datenbankmanagement-System zugrunde liegt, das die Kombination OLAP und OLTP ermöglicht. Auf der SAP-HANA-Datenbank werden die Daten des SAP-S/4HANA-Systems in physischen Tabellen komprimiert und gespeichert.
Mittels SAP-HANA-Views können Sie Daten direkt in der Datenbank analysieren, berechnen oder selektieren. Es wird zwischen folgenden View-Typen unterschieden:
Attribute Views – werden eingesetzt, um Stammdaten und Attribute zu kombinieren und zu lesen. Attribute Views werden häufig wiederverwendet, beispielsweise für Sachkontenstammdaten.
Analytic Views – dienen dazu, Bewegungsdaten und Fakten zu lesen oder berechnete Spalten (Calculated Columns) zu generieren.
Calculation Views – bilden eine Kombination von Tabellen, Attribute Views, Analytical Views sowie Calculated Columns, um komplexe Datenmodelle zu erstellen oder Bewegungsdaten und Fakten zu lesen. Calculation Views können sowohl grafisch als auch SQL-basiert erstellt werden.
In früheren Versionen von SAP HANA hatten alle drei View-Typen ihren eigenen definierten Verwendungszweck. Im Laufe der Jahre wurden Funktionen der Analytic Views in die Calculation Views überführt. Heute ersetzen Letztere zunehmend die Analytic Views und sind die zukunftsorientierte Wahl.
SAP-HANA-Views können mittels Eclipse (inkl. SAP-HANA-Add-on), SAP HANA Studio und SAP Web IDE erstellt werden. Sie erfahren mehr zu diesen Tools in Kapitel 4.
Das virtuelle Datenmodell (Virtual Data Model) dient dazu, Datenbank-Views zu strukturieren, die die Daten mittels SQL von der Datenbank abrufen. In der schematischen Darstellung sind die ABAP-CDS-Views (hierzu gleich mehr) im virtuellen Datenmodell hierarchisch strukturiert. Im Wesentlichen werden auf unterster Ebene des Modells Bewegungs- und Stammdaten in getrennten Views von der Datenbank gelesen. Über verschiedene Ebenen und View-Typen hinweg werden diese Daten bis hin zur Query View konsolidiert.
»CDS« steht in diesem Kontext für Core Data Services. ABAP-CDS-Views sind das Pendant zu SAP-HANA-Views und werden im ABAP-Stack des SAP-S/4HANA-Systems entwickelt (verfügbar seit ABAP 7.40 SP8). Sie dienen wie SAP-HANA-Views zur Entwicklung von Datenmodellen und somit Datenbankabfragen. ABAP-CDS-Views werden mittels OpenSQL ausgeprägt. Durch den Code-Pushdown wird die Rechenleistung an die SAP-HANA-Datenbank ausgelagert; somit ist ein Performanceunterschied zwischen ABAP-CDS-Views und SAP-HANA-Views kaum zu spüren. Im SAP-S/4HANA-Kontext wird zwischen nachfolgenden CDS-Views unterschieden:
Private/Basic Views – Private oder Basic Views greifen direkt auf Datenbanktabellen zu. Sie dienen in der Regel dazu, Daten einer Tabelle bereitzustellen, damit diese in anderen Views wiederverwendet werden können.
Interface-/Composite Views – Mit Interface-/Composite Views (zusammengesetzten Views) werden mehrere Basic Views konsolidiert. Es werden beispielsweise die Sachkontentexte (SKA1) zur Tabelle ACDOCA hinzugelesen.
Consumption-Views – Consumption-Views (Verbrauchs-Views) bilden die oberste Hierarchiestufe im Reporting-Modell ab. Sie setzen auf Interface-Views auf und konsolidieren die finalen Daten für den späteren Bericht.
Customer Specific Views – Zu jeder View können Customer Specific Views (kundenspezifische Views) erstellt werden. Damit ist es möglich, bestehende Views um bestimmte Merkmale zu erweitern, ohne diese zu modifizieren. Mittels Customer Specific Views können auch SAP-Standard-Views ergänzt werden. Mehr dazu können Sie in Abschnitt 5.2 nachlesen.
Die Reporting-Schicht dient zur Konsumierung und Visualisierung der Queries in SAP S/4HANA mittels SAP-Fiori-Applikationen. Für Standard-Queries bietet SAP viele Standardkacheln an, die nach vorheriger Aktivierung (siehe Kapitel 2) verwendet werden können. Für kundeneigene Queries bieten sich benutzerdefinierte analytische Abfragen an