Ein Überblick über Neuerungen und Änderungen mit BW/4HANA 2.0

Autor: Christian Albert | Veröffentlicht: 04.08.2020

Im ersten Teil der Serie ging es unter anderem um die Neuerungen in den BW Modelling Tools in Eclipse / HANA Studio. Der zweite Teil des Blogs behandelt weitere Neuerungen in den BW Modellierungswerkzeugen im Bereich der ADSO Handhabung. Es wird aber auch ein kurzer Blick auf neue Optionen im Bereich der Query Variablen und Neuerungen beim Datenflussmodell geworfen.

ADSO Remodellierung

Die Remodellierung eines ADSOs wird, wie bisher, immer dann notwendig, wenn das Datenmodell des ADSOs geändert wurde und Daten im ADSO vorhanden sind. Es besteht auch im BW/4HANA 2.0 die Möglichkeit, diese Remodellierung im bestehenden ADSO zu definieren und einen Remodellierungslauf zu starten. Die Remodellierungsvorschriften selbst können im zweiten Reiter Details des ADSOs vorgenommen werden. Bei der Auswahl eines Feldes / InfoObjekts wird der Schalter Remodellierung anwählbar. Im Vergleich zur bisherigen Remodellierung fehlt jedoch die Option für ABAP Logik. Es sind nur direkte Ableitungs- bzw. Ersetzungsmöglichkeiten auswählbar.

ADSO Remodellierungsoptionen

Diese Einschränkungen und die weiteren Einschränkungen bzgl. der zu ersetzenden Felder wie gleicher Datentyp, gleiche Länge, gleiche Konvertierungsroutinen, etc. lassen relativ wenige Szenarien für die direkte Remodellierung zu. So ist es bspw. auf Grund der Einschränkungen nicht möglich, ein Feld vom Type CHAR(10) durch eine InfoObjekt vom Typ CHAR(10) zu ersetzen, wenn das InfoObjekt eine Konvertierungsroutine hat, das Feld bisher jedoch nicht. Für die Details sei auf die SAP Online Hilfe verwiesen.

Eine weitere Restriktion für den Remodellierungslauf ist die Anzahl der Datensätze im ADSO (bzw. die Größe der Datentabelle). Da die Daten bei einem Remodellierungslauf über eine temporäre Tabelle verschoben werden kann es hier zu Problemen kommen. Ist das ADSO zu groß kann die temporäre Tabelle die Systemgrenzen bzgl. Speicherbedarf überschreiten. In so einem Fall bricht der Remodellierungslauf ab und lässt sich nur schwerlich wiederaufsetzen.

Da die Einschränkungen bei einem Remodellierungslauf nicht unerheblich sind würde ich empfehlen hier lieber mit einem temporären Schatten-ADSO zu arbeiten und über dieses die Daten zu kopieren. Die Verwaltung eines Remodellierungslaufs findet nun im BW Cockpit statt, ähnelt jedoch der bisherigen Verwaltung im SAP GUI.

ADSO Data Tiering

Das Data Tiering wurde leicht umgestaltet. Die Einstellungen für das Data Tiering können im Reiter Allgemein vorgenommen werden. Hier kann, sofern eine entsprechende Lösung vorhanden ist, die zur Verfügung stehende Datenbank Lösung für „cold“ ausgewählt werden. Steht ein HANA-Erweiterungsknoten zur Verfügung, so kann auch die Option warm ausgewählt werden.

ADSO DTO – Einstellungen

Für die Partitionierung auf Partitionsebene besteht die Möglichkeit, diese statisch zu definieren oder dynamisch. Bei der statischen Partitionierung werden die möglichen Partitionen fest vorgegeben. Es besteht die Möglichkeit, die Partitionsgrenzen über die Funktion „Splitten“ durch das System automatisch aufteilen zu lassen. In dem unten genannten Beispiel wurden als Grenzen nur das Kalenderjahr 2015 bis 2021 angegeben. Die Aufteilung erfolgte dann per Splitt automatisch auf die Kalenderjahre.

ADSO DTO – Automatischer Splitt

Erfolgt eine dynamische Partitionierung auf einem Merkmal, so muss man sich der Tatsache bewusst sein, dass für jeden neuen Wert auf dem Feld / InfoObjekt, eine neue Partition angelegt wird. Dieses Verhalten kann nur bei InfoObjekte basierend auf 0CAL* und 0FISC* InfoObjekten oder bei auf dem DATS Typ beruhenden Feldern übersteuert werden. In diesen Fällen kann mit Hilfe der dynamischen Partitionierung die Granularität der Partitionierung festgelegt werden.

Die Verwaltung der Partitionen erfolgt im BW Cockpit. Die Oberfläche ist ähnlich der bisherigen. Es besteht jedoch auch die Möglichkeit, die Partitionen regelbasiert automatisiert zu verwalten.

Noch eine kleine Anmerkung zur Gestaltung der Partitionen. Sie sollten so gestaltet sein, dass nicht zu viele Partitionen entstehen, die Partitionen sollten aber auch nicht zu groß werden. Werden die einzelnen Partitionen zu groß, so wird die Verwaltung ggf. unmöglich. Da die Partitionen als Tabellen verschoben werden kann eine zu große Partition die Systemgrenzen überschreiten. Hier muss für das jeweilige System die jeweilige Grenze im Vorfeld ermittelt werden und dann die Partitionen entsprechend dimensioniert werden.

Datenfluss

Unter BW/4HANA 2.0 wurde das Objekt Datenfluss erweitert. Die Beschreibungen in einem Datenfluss sind nun auch im HTML Format möglich.

Wie bisher gibt es zwei Arten von Datenflüssen:
  • Der transiente Datenfluss wird basierend bestehende Objekte ad-hoc erstellt. Es zeigt die bestehenden Datenobjekt an.

  • Die andere Art ist der Datenfluss als eigenständiges Objekt. Diesen Datenfluss kann als eigenständiges Objekt erstellt werden und mit Platzhaltern für die Objekte versehen werden, die für das zu beschreibende Szenario vorgesehen sind. Diesen Datenfluss und die Objekte darin kann man mit Beschreibungen und Namen versehen.

Aus dem Datenfluss heraus können die Objekte per Klick erstellt werden. Leider ist es nicht möglich Vorgaben bzgl. der Namenskonvention verbindlich zu hinterlegen. So kann der Name des Objektes zwar vorgegeben werden (bspw. als ADSO A5TB20nn im Datenfluss). Beim Anlegen des ADSOs aus dem Datenfluss heraus wird der Name jedoch nicht übernommen und kann komplett geändert werden.

Neue BEx Variablen Typen: BRF+ und HANA Exit

Eine Neuerung mit BW/4HANA 2.0 betrifft neue Bex Variablen Typen. Der BRF+ Typ (Business Rule Framework) soll es dem Fachbereich ermöglich, direkt selbst Regeln in einem Rahmenwerk anzulegen und diese dann in einer BEx Variable zu nutzen. Das Rahmenwerk umfasst dabei u.a. Entscheidungstabellen, Entscheidungsbäume, Formeln, Datenbankzugriffe.

Der andere Typ ist die BEx Variable vom Typ HANA Exit. Hier ist es möglich, die Logik der BEx Variablen in HANA SQL Script zu implementieren. Den Rahmen für eine derartige Implementierung bildet dabei der Erweiterungssport RSROA_VARIABLES_HANA_EXIT. Neben einigen spezifischen Einstellungen für diesen Erweiterungsspot (u.a. eine Fallback-Klasse, Angaben zur Verwendbarkeit) müssen in dessen Rahmen für eine Variable zwei Methoden angelegt werden.

In der einen Methode muss die BAdI Implementierung selbst als aktiv ausgewiesen werden, unter der die Variable bzw. die weiteren Variablen der BAdI Implementierung angelegt sind (Methode GET_PROPERTIES). Zum anderen muss die Logik der Variablen selbst hinterlegt werden (in der Methode PROCESS). Dies erlaubt es, wie schon aus anderen BAdI Implementierung der bisherigen BEx-Variablen bekannt, die einzelnen Bereiche für BEx Variablen zu clustern. Die Logik selbst wird dabei im SAP HANA Studio in der ABAP Perspektive in SAP HANA SQL Script implementiert.

Damit besteht die Möglichkeit bei der Variablenlogik die Performancevorteile von HANA zu nutzen, zum anderen kann hier auf die Vorzüge von SQL zurückgegriffen werden. Neben der Nutzung von CalculationViews und HANA Tabellen können auch simple SQL Befehle genutzt werden, deren Umsetzung im traditionellen ABAP aufwändiger wäre. So könnte die Anforderung aus den Daten eines ADSOs vom Typ Direct Input (wie im oben aufgeführten ADSO A1TB20UT1) den höchsten Schlüssel zu einem Text (wie bspw. „Main Plant“) zu finden mit Hilfe eines kurzen SQL Statements erfolgen. Die Abbildung 4 zeigt in den markierten Zeilen das Coding für eine solche Variable „LV_TB20T1_0PLANT_HVCO_01“. Im Coding wird dabei auf ein ADSO „U1TB20T1“ zugegriffen, welches identisch aufgebaut ist zum ADSO vom Typ „Direct Update“ aus dem ersten Blog zum Thema Neuerungen in BW4HANA 2.0. Als Ergebnis der Logik ist die Variable mit dem Werk 1710 befüllt. Eine gleichartige Implementierung in der bisherigen ABAP Variablenroutine wäre für diese Anforderung aufwändiger gewesen.

Beispiel SQL-Statement für ein BEx SQL Variablen

Für die genaueren Details der Umsetzung (Ausgestaltung des Erweiterungsspots, Gliederung der einzelnen BAdI Implementierungen, Ausgestaltung der Methoden, etc.) kann auf einschlägige Blogbeiträge in der SAP Community zurückgegriffen werden.

Fazit zu den BW Modellierungswerkzeugen

Im Bereich der Modellierungswerkzeuge haben sich die Änderungen und Anpassungen vornehmlich im Bereich des ADSOs abgespielt (jedenfalls bis zum Support Package 03). Dort gab es einige Änderungen eher kosmetischer Natur. Die Anpassungen bei den Funktionen umfassen die, aus meiner Sicht interessante und sinnvolle Option, Daten nun direkt in ein ADSO zu laden. Andere Anpassungen im Bereich des ADSO wie bei der Remodellierung sind noch nicht so mächtig wie im SAP GUI Umfeld und daher nur mit Einschränkungen zu nutzen. Wie andere Neuerungen, bspw. im Datenfluss genutzt werden können, hängt vornehmlich davon ab, wie hier die bisherige Handhabung im jeweiligen System erfolgt und ob bereits andere Tools dafür genutzt wurden.

Die neuen BEx Variablen Typen sind sicher ebenfalls interessant und können in dem einen oder anderen Fall ein gute Option sein, um Anforderungen schneller und einfacher implementieren zu können. Alles in allem sind die Neuerungen hier überschaubar und für einen erfahrenen SAP BW Betreuer ohne große Mühen anwendbar. In den kommenden Teilen des Blogs werden die Neuerungen im Bereich des BW Cockpits betrachtet. Die neue Oberfläche, so viel schon mal an dieser Stelle, lässt manches in einer neue Perspektive erscheinen.

Zurück zum Analytics-Blog

Der Blog hat Ihnen gefallen und Sie wollen gerne direkt per E-Mail benachrichtigt werden, wenn der nächste Artikel erscheint? Gerne geben wir Ihnen Bescheid!

Ansprechpartner SAP Analytics Blog Sascha Hanf

Haben Sie Fragen?

Sascha Hanf ist Ihr Ansprechpartner für den Analytics Blog.

Jetzt Kontakt aufnehmen
Ansprechpartner SAP Analytics Blog Sascha Hanf

Haben Sie Fragen?

Sascha Hanf ist Ihr Ansprechpartner für den Analytics Blog.

Jetzt Kontakt aufnehmen