Neuerungen beim CompositeProvider mit BW/4HANA 2.0 SP04 – Ein Überblick
In diesem Blogbeitrag sollen einige der Neuerungen des CompositeProviders, die im Rahmen des Support Packages 4 für SAP BW/4HANA 2.0 eingeführt wurden, beleuchtet werden.
Überblick über die Neuerungen
Der CompositeProvider als virtueller InfoProvider ist im BW/4HANA schon lange eingeführt. Gegenüber dem MultiProvider, seinem Vorgänger, war er schon mit mehr Optionen ausgestattet. So konnten in ihm auch Joins genutzt werden (man musste also kein InfoSet mehr nutzen) und auch Kombinationen aus Union und Joins waren bereits möglich. Allerdings mit einigen Einschränkungen: So war die Verwendung von Left Outer Joins und Unions nur auf der untersten Ebene in einem CompositeProvider realisierbar. Aus diesem Grund wurden in vielen Projekten für Modellierungen mit Joins bzw. Kombinationen aus Union und Joins sowie bei komplexeren Modellierungsanforderungen (wie Erweiterung der Felder durch berechnete Spalten) andere Optionen genutzt (bspw. CalculationViews, CDS-Views).
Mit dem Support Package 4 für BW/4HANA 2.0 hat die SAP die Funktionen des CompositeProviders erheblich erweitert. Alle Erweiterungen werden ausführlich in den Release-Informationen der SAP beschrieben. Einige möchte ich hier explizit aufführen:
- Die Einschränkungen bei der Reihenfolge von Joins und Unions wurden aufgehoben, d.h. nun kann ein Union auch auf der obersten oder in einer Zwischenebene erfolgen.
- Ein Part Provider kann mehrfach vorkommen.
- Neue Join Typen wie Full Outer und Right Outer sind nun möglich.
- Ein Feld kann nun direkt in der Zielstruktur angelegt oder dort dupliziert werden.
- In der Zielstruktur können nun berechnete Felder definiert werden.
- SQL-Filter können definiert werden.
- Es besteht die Möglichkeit, eine Aggregations- oder eine Projektions-Ebene anzulegen.
Ein paar dieser Funktionen sollen nun an Hand kleiner Beispiele gezeigt werden.
Überblick über das Datenmodell der Beispiele
Zuerst aber ein Blick auf das Datenmodell, welches hier verwendet werden soll.
Vorab eine kleine Anmerkung zum Datenmodell: Das Datenmodell selbst wird man in einer realen Umsetzung nicht unbedingt so implementieren. Aber diese einfachen Spieldaten sind für die Demonstration einiger der oben aufgeführten neuen Features ausreichend.
Die Grundgedanken für das Testszenario sind diese: Grundlage der Daten bildet ein Union, der die in zwei ADSOs semantisch partitionierten Grunddaten (über Kalenderjahre) zusammenführt (ADSOs Grunddaten). Die beiden Datentöpfe mit den Grunddaten werden dabei vorher jeweils mit einem Join mit weiteren Daten aus dem Bereich CO angereichert (ADSO CO-Daten). Dieses CO-Daten ADSO wird also zweimal im CompositeProvider verwendet. Darüber hinaus werden die im Union zusammengeführten Daten in einem letzten Join noch mit Daten aus dem Bereich SD weiter angereichert (aus dem ADSO Vertriebs-Daten).
Man erkennt, dass der Aufbau der ADSOs sehr ähnlich ist und immer die gleichen Schlüsselfelder beinhaltet.
Modellierung des CompositeProviders mit Union
Mit diesen ADSOs beginnt nun die Modellierung des CompositeProviders. Die Modellierung erfolgt dabei nicht über den Wizzard, sondern komplett manuell. Der Wizzard würde nämlich den Union in alter Gewohnheit auf der untersten Ebene ansetzen.
Zuerst werden die beiden Joins erstellt: Für die Grunddaten existieren zwei ADSOs, da die Daten in diesen ADSOS ja jeweils nach Jahren getrennt sind. Zur Anreicherung der CO-Daten wird in beiden Joins auf das gleiche ADSO mit den CO-Daten zurückgegriffen.
Die beiden Join Provider führen jeweils ein ADSO für Grunddaten mit dem ADSO für die CO-Daten zusammen.
Diese beiden Joins werden dann in einem Union zusammengeführt.
Die Zuordnungen im Union werden z.T. automatisch angelegt, teilweise muss noch eine Zuordnung von Hand erfolgen. Allerdings kann die Zuordnung auch im Paket durchgeführt werden, indem mehrere Felder markiert werden.
Nun wird der Union noch mit Hilfe eines Joins um die Vertriebsdaten erweitert. Dazu wird beim Union-Symbol das Icon für den Join ausgewählt und das gewünschte ADSO über die Suchhilfe in die Auswahl aufgenommen.
Wie im oberen Bild zu sehen, kann das gewünschte ADSO über die Suchhilfe ausgewählt werden. Die nächste Darstellung zeigt, wie die Schlüsselfelder (aus dem Union und dem ADSO mit den Vertriebsdaten) in die Join-Bedingungen aufgenommen wurden.
Bei genauerem Blick auf das obige Szenario könnte der referentielle Join etwas verwundern. Ein normaler Inner Join sollte auch die gewünschten Ergebnisse liefern. Er ließ sich jedoch auf dem System (mit SP04 und SP05) nicht aktivieren, die Aktivierung brach mit einem Kurzdump ab. Dies scheint mir aber ein Bug zu sein. Der OSS-Hinweis 2887964 beschreibt ein ähnliches Verhalten und wird mit SP07 ausgeliefert – wir werden sehen, ob sich dann der CompositeProvider mit dieser Join Option aktivieren lässt.
Interessanterweise lässt sich die Option mit dem Inner Join aktivieren, wenn die beiden Join Partner getauscht werden. Diese Möglichkeit am Join Knoten ist in der nächsten Abbildung markiert – das Bild zeigt aber den CompositeProvider, nachdem die Join Partner getauscht wurden.
Die Stabilität der neuen Option ist daher in einigen Bereichen sicherlich noch nicht optimal. Es ist aber davon auszugehen, dass sie sich zeitnah verbessern wird und die Lösungen im Bereich des CompositeProviders zu den anderen Optionen aufschließen wird.
Wie oben schon mal erwähnt, ist das Datenmodell sicher ein Modell, welches man so in der Realität nicht modellieren würde.
Filteroption im CompositeProvider
Im CompositeProvider können nun auch direkt Filter gesetzt werden, um bspw. die Daten aus einem Partprovider entsprechend zu filtern. Die Dokumentation für das SP04 beschreibt, dass ein Filter nur in einem Projektions- oder Aggregationsknoten erstellt werden kann – auf unserem System mit SP05 konnte der Filter auch in Joins und Unions gesetzt werden.
In einer Projektion bzw. Aggregation wird der Filter direkt im jeweiligen Knoten gesetzt, wie in der folgenden Abbildung dargestellt.
Die Filter müssen in SQL ausgeprägt werden. Dabei stehen auch SQL-Operatoren zur Verfügung, die in der Filterbedingung genutzt werden können. In unserem Beispiel beschränke ich mich aber darauf, nur Ergebnisse eines fixen Werks anzuzeigen. Ein aktiver Filter wird in der Projektion mit einem kleinen Filter-Symbol angezeigt.
Berechnete Felder im Composite Provider
Filter können auf Ebene von Knoten (sowohl wie in der Dokumentation beschrieben auf einem Projektions- oder Aggregationsknoten als auch auf Knoten für Joins und Unions – zumindest ab SP05) angelegt werden. Die Option dafür steht in der Definition eines Knotens zur Verfügung.
Das Feld selbst kann als Merkmal oder als Kennzahl ausgeprägt werden. Die Definition der Berechnung erfolgt über einen SQL Ausdruck. Es stehen auch hier vordefinierte SQL-Operatoren zur Verfügung, auf die zurückgegriffen werden kann. So steht bspw. eine Funktion zur Verfügung, die die Anzahl der Tage zwischen zwei Datumsfeldern berechnet. Allerdings muss hier, im Unterschied zu den Calculated Columns im Calculation View, der komplette Ausdruck in SQL geschrieben werden. Hilfen, wie vorhandene Spalten, stehen hier nicht zur Verfügung. So muss eine Spalte selbst in die Definition geschrieben werden und kann nicht per Drag & Drop eingefügt werden.
Im Beispiel für diesen Blog soll aber nur der einfache Fall für eine Kennzahl in Hauswährung dargestellt werden. Es findet keine Berechnung statt (die man im else-Zweig vornehmen könnte), sondern nur eine einfache Fortschreibung für den Fall, dass die Währung im Datensatz EUR ist.
Man sieht, dass man sich hier in der SQL-Definition auch an erheblich komplexere Ausdrücke wagen könnte und damit komplexe Anforderungen abbilden kann.
Das Ergebnis der oben gezeigten SQL-Definition stellt sich dann in der Spalte „Hauswährung“ so dar:
Fazit
Zeit für ein kurzes Fazit der neuen Möglichkeiten beim Composite Provider.
Mit den neuen Möglichkeiten sind die Funktionen beim Composite Provider mächtiger geworden und haben die Lücke in diesem Bereich gegenüber den anderen Optionen (CDS Views und Calculation Views) verkleinert. Man kann wohl damit rechnen, dass SAP weitere Funktionalitäten entwickeln wird und damit die Option Composite Provider attraktiver werden wird. Bzgl. der Handhabung ist festzuhalten, dass der Composite Provider sicherlich einfacher zu bedienen ist als die anderen Optionen für die Modellierungsanforderungen. In Teilbereichen jedoch ist die Nutzung (noch nicht) so komfortabel wie bspw. beim Calculation View. Wie sich der CompositeProvider im Bereich Performance schlägt, wurde hier nicht untersucht und muss im Einzelfall für die jeweilige Umgebung detailliert betrachtet werden.
Bei der Auswahl des jeweiligen Ansatzes für die Modellierung sollte man sich auf eine bestimmte Option (aus den drei Optionen CompositeProvider, Calculation View, CDS-View) für einen definierten Anwendungsfall festlegen. Man sollte daher vorgeben, wie bspw. Stammdaten angereichert werden sollen – in einem CalculationView oder in einem CompositeProvider.
Abschließend lässt sich festhalten, dass der CompositeProvider mit den neuen Features gegenüber den anderen Optionen weiter aufgeholt hat.
Mit diesem Blogbeitrag ist die Betrachtung der Neuerungen mit SAP BW/4HANA 2.0 abgeschlossen.
Wir werden aber trotzdem weitere Neuerungen beobachten und in weiteren Blogbeiträgen beleuchten.