In unserem vorherigen Blog-Artikel BW/4HANA – Funktionen und Innovationen eines modernen Data Warehouse aus unserer Reihe „Modern Data Warehousing“ haben wir beschrieben, welche Möglichkeiten und Potenziale es gibt, ein BW/4HANA als zentrale Informations- / und Datenplattform aufzubauen.
Im aktuellen Blog möchten wir Ihnen anhand ganz konkreter Anforderungen und deren Umsetzung zeigen, wie BW/4HANA mit seinen technologischen Neuerungen zu einfachen, schnellen und flexiblen Lösungen führen kann.
DSGVO Reporting – Beauskunftung im Business-To-Employee (B2E) Umfeld
Über das Thema DSGVO haben wir bereits in zwei Blogartikeln informiert. Aktuell taucht dieses wieder vermehrt in den Medien auf, da erste Unternehmen zu Geldstrafen verurteilt wurden. Dass ein Unternehmen auch gegenüber seinen Angestellten eine Auskunftspflicht hat, wo und wie personenbezogene Daten in Systemen des Unternehmens gespeichert werden, ist für einige sicher neu. Um dieser Auskunftspflicht nachzukommen, liegt es nahe, hierfür eine Analyse in einem Data Warehouse bereitzustellen. Erst recht, wenn ein Großteil der Prozessdaten, die personenbezogene Daten enthalten, aus den unterschiedlichsten beteiligten Systemen bereits für das Berichtswesen zentral verfügbar sind.
In einem konkreten Fall sollte eine Lösung bereitgestellt werden, die:
- für verschiedene Felder wie User-IDs, Partner-ID, Email-Adressen usw.
- in einer ODER Verknüpfung bei Mehrfachauswertungen in einem SAP Frontend wie z.B. AfO
- in kurzer Ausführungszeit
- die Verwendungsart („customizebarer“ Text pro Merkmal und Fundstelle) und den Verwendungsort
zurückgibt. Die Lösung sollte im Hinblick auf die Auswahl der zu berücksichtigten Felder und Datenbasis einfach erweiterbar sein.
Eine erste Herausforderung ergibt sich daraus, dass in einem historisch gewachsenen Data Warehouse teilweise inhaltlich gleiche Informationen (wie eine User-ID) in einzelnen Teilapplikationen des Data Warehouse technisch nicht über das gleiche Merkmal (oder per Referenz) abgebildet werden und damit nicht ohne Weiteres im virtuellen Datamart Layer zusammengeführt werden können. Ähnliches gilt für die Anforderung, dass im Frontend das Ergebnis als ODER Verknüpfung zurückgeliefert werden soll – also zeige die „Fundstellen“ für User AB, Email oder Adresse XY über einen Abfragevorgang.
Mit BW/4HANA wurde die Lösung als Mixed Szenario umgesetzt, d.h. es wurden SAP BW Objekte (bereits vorhandene Datenbasis in Form von Advanced Datastore Objects) mit HANA nativen Objekten kombiniert. Folgendes Schaubild beschreibt den Aufbau der Lösung:
Die Datenbasis bildeten DDIC Tabellen (z.B. Systemtabellen für Userinformationen), Advanced Datastore Objects (Bewegungsdaten des Reportings) und Stammdatentabellen. Auf diese BW Objekte wurden applikationsspezifische Calculation Views erstellt und in einem weiteren Calculation View für das Abfragemerkmal zusammengeführt und auf ein einheitliches Merkmal gemappt. In einem übergreifenden Calculation View wurden dann die verschiedenen Abfragemerkmale mit Daten aus dem Customizing kombiniert.
Zentraler Baustein des übergreifenden View ist eine Tablefunction, in der mit HANA SQL Script die Daten aus den einzelnen Merkmalsviews entsprechend der mitgegebenen View Parameter selektiert und per UNION kombiniert (Umsetzung der ODERVerknüpfung) werden.
Der zentrale Calculation View wurde dann in einen Composite Provider integriert und bildete damit die Basis für die Query. Innerhalb der Query konnten dann mit Standard Variablen die Parameter des Calculation Views befüllt werden, um eine performante Selektion der Daten zu gewährleisten.
Durch das Zusammenführen von unterschiedlichen technischen Merkmalen in ein konsolidiertes Feld im Calculation View ging bei der Queryausführung die von BW Usern gewohnte Möglichkeit verloren, bei der Variableneingabe über die Wertehilfe das Berichtsergebnis einzuschränken. Aber auch dieses Problem wurde mit der Möglichkeit der Modellierung von virtuellen Stammdaten im BW/4HANA gelöst.
Bei der finalen Queryausführung konnten somit Daten aus mehr als 50 Quellen mit über 100 Mio. Datensätzen in Laufzeiten von unter 3 Sekunden ausgewertet werden.
Löschsatzermittlung für kundeneigene Extraktoren
Für ein bekanntes Problem bei der FULL Extraktion von Daten aus Quellsystemen bietet BW/4HANA ebenfalls eine neue innovative Möglichkeit einer Lösung. Eigentliches Problem ist, dass bei der FULL Extraktion keine Informationen für in der Quelle gelöschte Sätze ermittelt werden und somit nach dem Load im BW Sätze vorhanden sind, die im Quellsystem eigentlich gelöscht sind. Bisher hat man dies i.d.R. über eine weiter persistente Schicht im BW oder das komplette Löschen der Eingangsschicht im BW gelöst. Nachteil dabei ist entweder zusätzliches Datenvolumen (einer 2. Schicht) oder lange Laufzeiten durch das komplette Löschen und damit nicht mehr mögliche Deltaverarbeitung im nachgelagerten Datenfluss.
Seit BWonHANA 7.5 SPS04 gibt es im SAP Standard über die Option Snapshot Support im aDSO eine Funktion, die genau dies abbildet. Um diesen zu nutzen wird aber bei jedem Load der komplette Datenbestand aus der Quelle benötigt. Einen rollierenden FULL Load (z.B. rollierend die Daten der jeweils letzten 12 Monate) kann mit dieser Option nicht umgesetzt werden, da Daten außerhalb der Selektion als „in Quelle gelöscht“ interpretiert werden und somit ebenfalls im aDSO entfernt werden.
Zentraler Bestandteil der Lösung, die Löschsätze auch für einen rollierenden FULL Load erkennt, ist ein SAP HANA Analyse Prozess. Folgendes Schaubild zeigt den Aufbau dieser Lösung:
Die Daten werden per FULL aus der Quelle in ein aDSO geladen. Nach dem Load sind damit alle Sätze der Quelle vorhanden und aktualisiert. Allerdings sind aber noch Sätze im BW vorhanden, die seit dem letzten Load in der Quelle gelöscht wurden. Um diese ebenfalls zu löschen, wird ein HANA Analyseprozess ausgeführt, der per SQL Script die Daten des aDSO mit den Daten der Quelle (verfügbar als Open ODS View in Verbindung mit SmartDataAccess – SDA) für die gleiche Selektion des aktuellen FULL-Loads vergleicht, um die Löschsätze zu ermitteln (EXCEPT Statement) und diese über den entsprechenden Recordmode zur Löschung ins aDSO fortschreibt.
Bei unserem Kunden konnten wir mit dieser Lösung mit einem Datenvolumen von über 500 Mio. Datensätzen in der Quelle problemlos im täglichen Ladezyklus umgehen.
Mapping Kennzahlmodell <-> Kontenmodell
Ob ein BW Modell als Kennzahlen- oder Kontenmodell aufgebaut werden soll, hängt maßgeblich von der fachlichen Anforderung an das Reporting ab. Teilweise wird aber auch durch die bereitgestellten Extraktoren ein bestimmtes Modell vorgegeben, das ohne größere Anpassungsaufwände zu investieren, verwendet werden muss. Die Transformation von einem Modell ins andere wurde bislang klassischerweise über eine zusätzliche persistente Schicht innerhalb des BW abgebildet. Dabei wurde das zu berücksichtigende Mapping meistens in Form von Tabellen (Customizing- oder Stammdatentabellen) in Verbindung mit ABAP Coding in der Transformation angewendet. Der Hauptnachteil dieser Lösung wird bei Änderungen des Mappings deutlich, da hier der komplette Datenbestand erneut geladen werden muss, um die neuen Mappingregeln anzuwenden.
Auch in diesem Beispiel bietet ein modernes Data Warehouse wie BW/4HANA mit den Möglichkeiten, virtuelle Datenmodelle zu erstellen, entscheidende Vorteile. Im konkreten Fall sollten aus einem ERP System Daten aus den Tabellen COSP und COSS im BW bereitgestellt werden und dabei die Kennzahlfelder (pro Periode eine separate Kennzahl) in eine Zielstruktur mit nur einer Kennzahl und mehreren Datensätzen transformiert werden. Die Umsetzung erfolgte dabei über eine Calculation View die als Grundlage für die Datenbereitstellung im BW diente.
Wie man anhand der beschriebenen Beispiele sehen kann, gibt es mit BW/4HANA* neue Mittel und Wege, einerseits zukünftig neue Anforderungen umzusetzen und anderseits bestehende Datenmodelle zu optimieren.
*mit BWonHANA in einem aktuellen Release / SPS Stand sollten die hier beschriebene Bsp. ebenfalls umsetzbar sein.
Haben Sie weitere Fragen? Wir sind für Sie da!