Ein Überblick über Neuerungen und Änderungen mit BW/4HANA 2.0
Mit der Version SAP BW/4HANA 2.0 wurden durch die SAP wieder etliche Neuerungen und Anpassungen in der Business Warehouse Lösung eingeführt. Doch diese beschränken sich nicht nur auf neue Funktionalitäten. Es gibt auch eine neue GUI, in der nun Funktionen des SAP BW/4HANA 2.0 verwaltet werden können: Das BW Cockpit.
In einem mehrteiligen Blog sollen nun einige Neuerungen und Anpassungen vorgestellt werden.
In den ersten Teilen geht es um allgemeine Neuerungen und die Neuerungen in den BW Modelling Tools in Eclipse / HANA Studio. In den weiteren Teilen werden dann die Neuerungen aus dem Bereich des BW Cockpit behandelt.
Es können aber bei weitem nicht alle Neuerungen im Rahmen dieses Blogs aufgeführt werden. Der betrachtete Umfang reicht bis zum Support Package 03.
Im Support Package 04 wurde der CompositeProvider um etliche Optionen in der Modellierungssicht erweitert. So wurde bspw. die Einschränkung bezüglich der Einschränkung in der Reihenfolge Union und Joins aufgehoben. Damit bietet der CompositeProvider nun Modellierungsmöglichkeiten, die bisher einem CalculationView vorbehalten waren. Es ist daher geplant, die Modellierungsoptionen mit diesen neuen Optionen ausführlich in einem eigenen Blogbeitrag zu behandeln.
Allgemeine Neuerungen
Zu den allgemeinen Neuerungen die mit BW/4HANA 2.0 verfügbar werden zählt die Data Protection Workbench. Die Anforderungen an den Datenschutz im IT-Umfeld haben ja nicht zuletzt durch die DSGVO an Bedeutung gewonnen. Bisher mussten derartige Lösungen im BW Umfeld (und im Verbund mit SAP Quell-System) selbst konzipiert und implementiert werden.
Mit der Data Protection Workbench stellt die SAP nun eine Lösung vor, die einen systemübergreifenden Ansatz darstellt. Mit dieser Lösung ist es möglich, Daten, welche in den Quell-Systemen als relevant für Löschanforderungen erkannt wurden, im BW in den relevanten Datenflüssen zu kennzeichnen. Liegen dann Löschanforderungen aus den Quell-Systemen für diese Daten vor, können diese Löschanforderungen mit Hilfe der erkannten Datenflüsse und Objekten an das BW-System übergeben und dort gelöscht / anonymisiert werden.
Die Lösung im BW basiert dabei auf einem contentbasierten Ansatz und unterliegt eigenen Lizenzvereinbarungen. Neben den technischen Aspekten (Zusammenwirken der Systeme, Einrichten der Lösung in den Quell-Systemen und im BW-System) sind hier auf jeden Fall noch in erheblichen Umfang sowohl rechtliche als auch fachliche Anforderungen zu klären. Als Beispiel für eine fachliche Fragestellung sei hier die einfache Anonymisierung bspw. der Kundendaten durch das Ersetzen mit Herr/Frau Max/Karin Mustermann in Musterstadt zu nennen. Hier würde sowohl das Ersetzen aller Kunden mit einem Pseudonym als auch das reine Löschen der Daten in den Auswertungen zu falschen Daten führen.
Eine weitere Neuerung stellt das Read Access Logging da. Hier können die Zugriffe auf definierten Daten über einen bestimmten Zeitraum hinweg nachverfolgt werden. Die Nachverfolgung kann dabei auf Ebene von InfoObjekte und InfoProvidern erfolgen. Neben Customizing Einstellungen müssen die entsprechenden Einstellungen am jeweiligen Objekt im Editor in den BW Modeling Tools vorgenommen werden.
Neuerung in den BW Modeling Tools
Im Bereich des SAP HANA Studios (bzw. unter Eclipse) gibt es in BW/4HANA 2.0 einige Neuerungen und Anpassung in den Editoren.
Währungsumrechnungsart / Einheitenumrechnungsart / Stichtagsableitungsart
Eine einfache Neuerung ist der Verlagerung der Einstellung zu den Währungs- und Einheitenumrechnungsarten bzw. der Stichtagsableitung aus dem SAP GUI ins SAP HANA Studio / Eclipse. Das eigentliche Erscheinungsbild und die Funktionalität haben sich dabei nicht geändert. Neu ist nur der Ausgangspunkt zur Pflege: dieser ist nun eine Option im Projekt Editor (siehe Abbildung 1: Anlegen einer Währungsumrechnungsart).
ADSO
In den BW Modeling Tools hat der Editor für ADSOs die meisten Änderungen erfahren. Zum Teil handelt es sich dabei nur um optische Änderungen, zum Teil aber auch um funktionale Änderungen und Erweiterungen.
Auf dem ersten Reiter Allgemein erkennt man die oben erwähnte Möglichkeit der Protokollierung des Lesezugriffs. Diese kann ganz oben aktiviert werden. Darüber hinaus fallen einige weitere optische Änderungen sofort ins Auge. Der bisher vorhandene Vorlagen Wizzard ist entfallen. An seiner Stelle finden sich nun in den Modellierungseigenschaften die möglichen ADSO Typen sowie die Möglichkeit, weitere Eigenschaften des ADSO festzulegen. Bei Bedarf liefert die Hilfe zu dem jeweiligen Typ noch den Verwendungszweck wie aus dem Wizzard bekannt.
Neu ist hier der ADSO Typ für ein ADSO mit direkter Fortschreibung. Dieser ADSO Typ wird weiter unten noch genauer erläutert. Ebenfalls erkennt man, dass die Eigenschaften des ADSOs für das Data Tiering nach rechts gewandert sind. Hier können nun direkt die Speicherbereiche für die Daten des ADSOs angegeben werden. Die weitere Detaillierung kann dann im Reiter Einstellungen festgelegt werden. Hier gab es keine großen Änderungen. Auf das Thema Data Tiering Optimization wird im Blog weiter unten noch eingegangen.
Im Reiter Details ergaben sich kaum Änderungen. Neu ist hier die Schaltfläche für die Remodellierung. Diese wird ebenfalls noch weiter unten detailliert beschrieben werden.
Neuer ADSO Typ: Direkte Fortschreibung
Betrachten wir den neuen ADSO Typ der direkten Fortschreibung etwas genauer. Dieser ADSO Typ erlaubt es, Daten aus einer Excel oder csv-Datei direkt in das jeweilige ADSO zu schreiben. Eine vorgelagerte DataSource und eine Transformation sind nicht mehr nötig. Die Datei kann direkt aus einem Browserfenster ausgewählt und hochgeladen werden. Ein derartiges ADSO verfügt nur über eine aktive Tabelle und ist nicht delta-fähig. Die Daten aus der hochgeladenen Datei überschreiben also, falls der Schlüssel bereits vorhanden war, ggf. vorhandene Datensätze.
Das Hochladen der Datei erfolgt über den Button zum Verwalten des ADSOs und öffnet ein Browserfenster im BW Cockpit. In diesem besteht darüber hinaus die Option, eine Vorlage zu erzeugen und die Daten beim Hochladen zu prüfen.
Direkt nach dem Hochladen stehen die Daten zur Verfügung.
Als mögliche Einsatzszenarien für dieses ADSO könnte das Laden von ad-hoc Daten aus dem Fachbereich, die eine Auswertung ergänzen, sowie Steuerungs- und Mappingdaten vorstellbar sein. Das Beladen kann direkt durch den Fachbereich erfolgen, ohne Beauftragung der IT.
ADSO: Externe SQL-View
Eine weitere Neuerung stellt der externe SQL-View da. Wie in Abbildung 3 ersichtlich, wird dieser mit BW/4HANA 2.0 für jedes ADSO bereitgestellt. Dieser View ist als bevorzugte Zugriffsmöglichkeit für interne Zugriffe auf die Daten eines ADSOs im BW gedacht. Die SAP verweist explizit darauf, dass der Zugriff bspw. in Start-, End- und Merkmalsroutinen nicht auf die Tabellen (wie bspw. aktive Tabelle /BIC/Axxx2) erfolgen soll, sondern auf diesen SQL-View (Tabelle /BIC/Axxx8). Dieser View bietet daher keine Funktionen wie Texte oder Berechtigungsprüfungen.
Die unterschiedlichen Zielsetzungen dieses SQL Views im Vergleich zum externen SAP HANA-View kann im Detail in der SAP Hilfe, im OSS Hinweis 2723506 und in einem Blog in der SAP Community nachgelesen werden.
Ein kurzer Vergleich der beiden externen Views in den nachfolgenden Abbildungen zeigt aber schon die unterschiedlichen Zielsetzungen. Der neue SQL-View (oben in Abbildung 6) bietet nur die reinen Daten und ein paar Verwaltungsfelder (wie bspw. ein Flag für Daten aus dem cold store) an. Der externe SAP HANA-View (unten in Abbildung 6) stellt dagegen um Texte (wie bspw. Texte zu Customer) angereicherte Daten zur Verfügung. Dieser View unterliegt auch einer Berechtigungsprüfung bei der Abfrage.
Im nächsten Teil des Blogs werden weitere Neuerungen im Bereich des ADSOs behandelt werden. Außerdem wird ein Blick auf eine Erweiterung im Bereich der Query geworfen, genauer auf neue Typen von BEx Variablen.
