Czytaj książkę: «Embedded Analytics in SAP S/4HANA»

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

SAP-HANA-Datenbank

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.

SAP-HANA-Views (physische Tabellen)

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.

Virtuelle Datenmodelle

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.

ABAP-CDS-Views

»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.

Reporting-Schicht

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 (siehe Kapitel 3).

1.2.1 InfoAreas

InfoAreas dienen der Strukturierung eines BW-Systems und somit der Gliederung von BW-Objekten, wie z.B. InfoObjects und InfoProvidern. In SAP S/4HANA Embedded Analytics sind die Standardauslieferungsobjekte ebenfalls in InfoAreas geordnet. Die InfoProvider von Finance gehören in die InfoArea Finanzkreis & Controlling – /ERP/FMCO (siehe Abbildung 1.2).

Abbildung 1.2: InfoArea »Finanzkreis & Controlling«

1.2.2 InfoObjects

InfoObjects sind typische Auswertungsobjekte aus SAP BW und werden u.a. gebraucht, wenn zeitabhängige Merkmale (Geschäftsjahr 0CALYEAR) als Selektionsparameter in Queries verwendet werden. InfoObjects unterscheiden sich in folgenden Eigenschaften:

 Merkmale (z.B. Buchungskreis; siehe Abbildung 1.3)

 Kennzahlen (z.B. Umsatz, Kosten)

 Einheiten (z.B. Währungen und Mengen)

 Zeitmerkmale (z.B. Geschäftsjahr, Monat)

 technische Merkmale (z.B. eine Request-ID)

Anzeige von InfoObjects

InfoObjects können Sie mit der Transaktion RSA5 installieren und mit der Transaktion RSD1 im SAP-S/4HANA-System anzeigen lassen.

In Abbildung 1.3 sehen Sie das InfoObject /ERP/COMPCODE – Buchungskreis, das im Standard ausgeliefert ist. In den Details auf der Registerkarte Allgemein können Sie beispielsweise sehen, welcher Datentyp sich hinter diesem InfoObject verbirgt und welche Zeichenlänge es hat.

Abbildung 1.3: InfoObject, Merkmal »/ERP/COMPCODE« – Buchungskreis, allgemeine Daten

Hinweis zur Einrichtung von SAP S/4HANA Embedded Analytics

Der Hinweis 2289865, »Configuration steps for SAP S/4HANA Analytics«, beschreibt die notwendigen Schritte, um Analytics in SAP S/4HANA On-Premises einzusetzen. Da die Schritte des Hinweises sehr technisch sind, empfehle ich Ihnen, diesen Hinweis durch Ihre SAP-Basis-Kollegen einspielen zu lassen.

Auf der Registerkarte Stammdaten/Texte (siehe Abbildung 1.4) erkennen Sie, dass dieses InfoObject ebenfalls ein InfoProvider ist, den Sie nutzen können, um beispielsweise direkt Daten zu Buchungskreisen in einer Query auszulesen. Darüber hinaus zeigt dieselbe Registerkarte, dass die dazugehörigen Daten über die SAP-HANA-View FCO_C_COMPANY_CODE von der Datenbank abgefragt werden.

Abbildung 1.4: InfoObject, Merkmal »/ERP/COMPCODE« – Buchungskreis, Stammdaten/Texte

1.2.3 InfoProvider

Der Ausdruck InfoProvider ist ein Oberbegriff für BW-Objekte. InfoProvider dienen als Datenlieferanten. Sie können Daten speichern (Daten werden in InfoProvider geladen) oder nur als Datenlesequelle (virtueller InfoProvider) genutzt werden.

Nachfolgende InfoProvider enthalten physische Daten:

 InfoCubes (siehe Abschnitt 1.2.5)

 DataStore-Objekte (dienen der Ablage von konsolidierten und bereinigten Bewegungs- oder Stammdaten auf Belegebene)

 InfoObjects als InfoProvider (direktes Lesen der Daten eines InfoObjects, z.B. in einer Query)

In den nachfolgenden Abschnitten werde ich auf virtuelle InfoProvider und InfoCubes näher eingehen, da sie die relevanten Objekte für Embedded Analytics sind.

Anzeige von InfoProvidern

Mithilfe der Transaktion RSA1 können Sie sich über Modeling • InfoProvider die ausgelieferten InfoProvider in Ihrem SAP-S/4HANA-System anzeigen lassen.

Abbildung 1.5 zeigt einen Ausschnitt aus der Transaktion RSA1. Hier sehen Sie den virtuellen InfoProvider S/4HANA Financials: Istdaten aus ACDOCA (/ERP/SFIN_V01), der im Standard ausgeliefert ist.

Abbildung 1.5: InfoProvider in SAP S/4HANA