SQL Ausdrücke in BW/4HANA Composite Provider (HCPR)

Veröffentlicht am 30. Dezember 2020 von

Jörg Brandeis

Mit dem SPS04 für BW/4HANA 2.0 hat die SAP einige nützliche Features in den Composite Provider eingebaut:

• Neue Join-Typen sind möglich: Full Outer-, Referential-, Right Outer Join
• Die Einschränkungen bezüglich der Reihenfolge von JOIN und UNION Knoten entfallen
• Mit den Operatoren <, >, <= , >=, != werden jetzt auch non-Equi Joins ermöglicht
• Projektions- und Aggregationsknoten können angelegt werden
• Es können mit SQL Ausdrücken berechnete Spalten definiert werden
• Die Daten können mit SQL Prädikaten die Daten gefiltert werden

Gerade die letzten beiden Punkte sind für mich als SQLScript Experten natürlich interessant. Es ergeben sich hier ganz neue Möglichkeiten, die ich in diesem Artikel analysieren möchte. Leider ist die Oberfläche für die SQL-Features eine Zumutung, weshalb ich hier auch ein Stück weit eine Anleitung für deren Anwendung gebe.

Die Unterschiede zu den Calculation Views (CV) der SAP HANA verschwinden zusehends. Nur die Modellierungsoberfläche für die CVs ist wesentlich komfortabler, gerade in der WebIDE. Auf diese auffällige Ähnlichkeit zu den CVs werde ich später noch mal eingehen.

Filtern in BW/4HANA Composite Providern mit SQL Ausdrücken

In jedem Knotentypen, außer den Part-Providern selber, ist es möglich einen SQL-Filter festzulegen. Dazu muss man über das Kontextmenü des jeweiligen Knoten gehen.

Die Oberfläche, die sich dann in einem Popup auftut, ist alles andere als selbsterklärend. Zunächst sieht es aus wie ein typischer Formeleditor. Weil es sich um einen Filter handeln soll, muss wohl ein Prädikat erfasst werden. Fangen wir also mit einem einfachen Vergleichsprädikat an. Hier stellt sich zunächst die Frage, wie wir uns auf Felder bzw. InfoObjects beziehen können. Leider fehlt eine entsprechende Unterstützung durch eine Werthilfe oder Auswahl und wir müssen wohl oder übel experimentieren. Hier bei stellt sich raus, dass wir uns auf die Namen im Target des jeweiligen Knotens beziehen müssen, wobei die spezielle Notation mit Gänsefüßchen und Großbuchstaben für Bezeichner zu verwenden ist. Fehler in den SQL-Ausdrücken werden erst beim Aktivieren des BW/4HANA Composite Providers angezeigt.

Die folgenden Prädikate funktionieren:

• Vergleichsprädikate mit den in der Auswahlliste angegebenen Vergleichsoperatoren
• Vergleich mit BETWEEN, z.B. "0CO_AREA" BETWEEN 'A' AND 'B'
• Mengenvergleich mit IN, z.B. "0CO_AREA" IN ( 'A' , 'B')
• LIKE zum Filtern mit einfachen Mustern
• LIKE_REGEXPR zum Filtern mit regulären Ausdrücken. Vorsicht: Der in der Auswahlbox vorgeschlagene Wert "like_regex" funktioniert nicht.
• IS (NOT) NULL - Das könnte praktisch sein, um die Daten von OUTER JOINs zu filtern und so das EXISTS Prädikat zu simulieren.
• CASE-Ausdrücke in Vergleichen

"0CO_AREA" = CASE "GXXMSSID" 
                  WHEN 'P01100' THEN 'ABC'
                  WHEN 'Q01100' THEN 'CDE'
                  WHEN 'D01100' THEN 'DEF'
                  ELSE ''
             END

Nicht erlaubt sind:

• Das EXISTS-Prädikat
• IN-Prädikat mit Unterabfrage
• Die Quantoren ANY, ALL und SOME

Damit fehlen leider alle Möglichkeiten zum Filtern mit Unterabfragen. Aber viele Dinge, die man mit EXISTS und IN/ANY/ALL/SOME mit Unterabfrage anstellen kann, lassen sich jetzt auch mit den erweiterten JOIN Bedingungen und Aggregationsknoten realisieren.

Mit SQL-Ausdrücken berechnete Felder im HCPR

Das Vorgehen bei den berechneten Feldern ist ganz ähnlich wie bei den Filtern. Über das Kontextmenü in dem rechten Target Bereich kann man das berechnete Feld anlegen. Ein modales Fenster wird angezeigt, in dem dieses Mal zusätzlich noch die Feldeigenschaften erfasst werden sollen:

• Gruppe
• Typ
• Name
• Beschreibung
• Assoziation mit
• Eindeutiger Name
• Checkbox Force Group By
• Datentyp & Länge

Mit den Erfahrungen aus dem Filtern habe ich hier auch wieder probiert, welche Ausdrücke erlaubt sind und welche nicht.

Erlaubte SQL Ausdrücke bei berechneten Feldern

• SQL-Funktionen aus der Auswahlbox - bis auf wenige Ausnahmen wie z.B. den oben schon erwähnten LIKE_REGEX. Hier sind aber auch SQL-Funktionen, die nicht in der aktuellsten Referenzdokumentation erwähnt werden. Beispielsweise die Funktion ABAP_EXTRACT_DAY( ). Diese ist aber auch ganz normal in der SQL-Konsole auf einer HANA Express verfügbar.
• Weitere SQL-Funktionen, die hier nicht gelistet sind. Beispiel hierfür wäre die SQL-Funktion WEEKDAY(), die sich ohne Weiters verwenden lässt, aber nicht zur Auswahl angeboten wird.
• Einfache und komplexe CASE Ausdrücke
• Literale, auch typisierte
• Felder aus der Target-Liste in spezieller Notation mit Gänsefüsschen und in Großbuchstaben

Und auch alle Kombinationen dieser Ausdrücke zu komplexeren Ausdrücken sind erlaubt.

Nicht erlaubte SQL Ausdrücke sind:

• Andere SQL-Funktionen, die in der SAP HANA bekannt sind, führen zu Fehlern beim Aktivieren des HCPR. Beispielsweise die RAND() Funktion.
• Aggregatfunktionen, auch nicht in Aggregationsknoten :-(
• Window Functions
• Sub-Queries

So bleibt einem nur ein Stück weit ausprobieren, welche Funktionen hier gehen und welche nicht. Gerade bei den SQL-Funktionen ist es sehr experimentell. Die Fehlermeldungen sind übrigens identisch mit denen der Calculation Views. Von daher vermute ich, dass es sich um die gleiche Menge an Features handelt, die hier erlaubt sind.

Kennt jemand eine übersicht, was dort erlaubt ist und was nicht?

Fazit zu SQL Ausdrücken in BW/4HANA Composite Providern

Die neuen Features sind schön, aber noch nicht 100% ausgereift. Konkret würde ich mir wünschen:

• Eine Werthilfe für die verfügbaren Felder in einem Ausdruck
• Eine komplette und korrekte Liste zur Auswahl der möglichen SQL-Funktionen
• Einen Ad-Hoc Prüfung der Syntax und nicht erst beim Aktivieren des HCPRs
• Lieber einen guten Code Editor mit Syntaxhighligting und Code Completion als einen schlechten Formeleditor
• Das alle angezeigten SQL-Funktionen auch in die SAP HANA SQL Referenzdokumentation aufgenommen werden
• Das auch die anderen SQL-Funktionen erlaubt werden, denn die Auswahl erscheint mir sehr willkürlich

Die anderen fehlende Features, beispielsweise die Window Functions, können sich extrem auf Ausführungsplan und Optimierung auswirken. Das will die SAP offensichtlich nicht riskieren. Das finde ich persönlich zwar schade, aber ich kann es gut nachvollziehen.

Nachtrag (29.1.2021): Ich habe heute in einem Projekt die Verwendung der beiden Features gesehen. Die Verwendung hat sich positiv auf die verwendete Architektur ausgewirkt, was mir wirklich gut gefallen hat.