XSA virtuelle Modellierung

Im vierten Teil unserer XSA-Blogreihe gehen wir im Detail auf die virtuelle Modellierung und das Reporting ein. Wie werden persistente Daten weiter aufbereitet? Welche virtuellen Modellierungsmöglichkeiten gibt es? Welche neuen Features haben XSA Calculation Views? Wie können Objekte in anderen HDI Containern selektiert werden? All diese spannenden Fragen werden wir in dem folgenden Blog beantworten.

Grundlagen der virtuellen Modellierung

Zuerst haben wir uns im ersten Blog die Grundlagen angeschaut, der zweite Blog hat die persistenten Strukturen erklärt. Im dritten Blog wurde das Thema Datenbeladung behandelt, sodass unser System auch einen Inhalt hat. Bei der virtuellen Modellierung treffen wir auf alte Bekannte aus der XSC Welt, die aber mit neuen Features wirklich begeistern können.

Ein der Stärken von In-Memory Datenbanken ist die virtuelle Modellierung. Im Gegensatz zu klassischen Datenbanken muss nicht mehr jede Logik persistiert werden, um gute Query-Zeiten zu erreichen. Viele der gängigen und auch komplexen Berechnungen können nun „on-the-fly“ ausgeführt werden.

Für die Modellierung ohne Persistenz bietet die XSA-Welt folgende 4 Objekttypen an, die in der folgenden Abbildung zusammengefasst sind.

Abbildung 1 – Artefakte zur virtuellen Modellierung

Für alle Objekte geben wir das folgende Beispiel: Wir möchten unsere beiden Tabellen BillHeader und BillItem joinen und eine Auswahl der Felder ausgeben.

CDS Views sind ein Teil von CAP, welches wir im zweiten Blog kurz angerissen hatten. Dabei handelt es sich um Views, die auf den Core Data Services basieren, eine eigene Syntax haben und im CAP Modell integriert sind. Sie können z.B. direkt in der schema.cds Datei hinterlegt werden, die wir in unserem Beispielprojekt erstellt haben. Da wir in unserem CDS Modell entsprechende Assoziationen hinterlegt haben, können wir auf diese direkt zugreifen und müssen nicht ein Join-Statement schreiben.

Abbildung 2 – Beispiel .cds view

Durch den Befehl „cds build“ wird das entsprechende Artefakt generiert, in diesem Fall eine .hdbview-Datei.

Abbildung 3 – Generierte .hdbview

Diese .hdbview-Artefakte können auch direkt selber geschrieben werden. Dieses Artefakt bietet die Möglichkeit „klassisches“ SQL zu schreiben und eine normale View zu definieren.

Abbildung 4 – Beispiel .hdbview

Eine Table Function bietet die Möglichkeit, SQLScript zu verwenden und damit auch weitere Elemente wie z.B. IF-ELSE Konstrukte einzubauen. Ein Nachteil der Table Functions ist, dass die Ausgabe fest ist und immer in korrekter Reihenfolge mit technischem Namen und Datentyp angegeben werden muss. Die folgende Table Function verwendet die Assoziationen und gibt Daten nur an einem Montag wieder.

Abbildung 5 – Beispiel .hdbfunction

Alle 3 bisher genannten Objekttypen sind stark an SQL angelehnt und Bedarfen entsprechender Vorkenntnisse. Des Weiteren ist die Optimierung dieser virtuellen Objekte stark abhängig vom Know-How des Entwicklers, da unter Umständen Joins oder Berechnungen ausgeführt werden, die für die eigentliche Query nicht wichtig sind.

Über viele Jahre hat SAP ein Objekt (weiter-)entwickelt, dass perfekt für Reporting-Zwecke eingesetzt werden kann: Calculation Views. Streng genommen müssen wir an dieser Stelle von HDI Calculation Views sprechen, da diese einen größeren Funktionsumfang als die klassischen Calculation Views im XSC Umfeld haben.

Abbildung 6 – Beispiel .hdbcalculationview

Diesen zentralen und elementaren Objekttyp wollen wir uns im folgenden Abschnitt genauer anschauen.

Calculation Views

Calculation Views sind in XSC Systemen weit verbreitet und werden z.B. im Mixed-Modelling Ansatz eines BW on HANA oder BW/4HANA Systems verwendet. Zusammengefasst bieten Calculation Views die Möglichkeit, über Knoten Standardfunktionalität (Projektionen, Joins, etc.) graphisch zu modellieren. Das Besondere an Calculation Views ist, dass nur die Logik ausgeführt wird, die von der Query gefordert ist. So können z.B. ganze Joins oder Berechnungen weggelassen werden, wenn die entsprechenden Felder nicht in der Selektion sind.

An dieser Stelle würde es diesen Blog sprengen, auf alle Features und Möglichkeiten der Calculation Views einzugehen. Daher beschränken wir uns hier auf ausgewählte neue Features in der XSA.

Folgende Knotentypen stehen für HDI Calculation Views aktuell zur Auswahl:

Abbildung 7 – Knotentypen XSA

Personen mit XSC Erfahrung sehen schnell, dass die XSA Welt einige neue Features anzubieten hat. So gibt es keine Beschränkung mehr auf Equi-Joins. Es können also Join-Bedingungen definiert werden mit anderen Operationen als Gleichheit:

Abbildung 8 – Non-Equi Joins

Ein sehr interessantes Feature für die Performanceoptimierung versteckt sich in den Eigenschaften eines Inner Joins:

Abbildung 9 – Optimize Join Columns

Wenn Spalten in einem Join-Statement angegeben werden, so werden diese in einer Query immer mitselektiert, auch wenn sie nicht explizit angegeben sind. Wenn die obere Option aktiviert ist, dann werden auch diese Spalte nicht selektiert, wenn der Join nicht benötigt wird. Dies ermöglicht eine noch stärkere Aggregation der Daten.

Ein lang ersehntes Feature ist die Möglichkeit der Windows Functions. Hierbei handelt es sich um analytische Funktionen, die auf der HANA Datenbank sehr performant ausgeführt werden können. In der Vergangenheit konnte dieses mächtige Werkzeug nur in Form von Table Functions realisiert werden, welche dann in Calculation Views als Projektion eingebunden wurden.

Durch den neuen Knoten „Window Function“ können diese nun direkt in einer Calculation View ausgeführt werden. Dabei stehen in der Pflege alle Funktionen zur Verfügung und die entsprechenden Parameter können graphisch gepflegt werden:

Abbildung 10 – Beispiel Window Function

Eine große Herausforderung bei der Arbeit mit SQL ist das Thema Debugging. Im Gegensatz zu imperativen Sprachen gibt es bei einem SQL-Statement keine Loops oder schrittweise Ausführungen. Ein Statement wird nur komplett ausgeführt oder nicht. Gerade bei komplexen und verschachtelten Views ist es daher schwer nach Fehlern zu suchen. Die Calculation View bietet dafür ein praktisches Feature: Debug View.

Abbildung 11 – Start Debug

Mit einem Klick auf diese Option öffnet sich ein euer Reiter in den Properties: Debug Query

Abbildung 12 – Generiertes Debug SQL

Dieser Reiter enthält zunächst ein generiertes SQL Statement, dass mit dem entsprechenden Button ausgeführt werden kann. Auf den ersten Blick scheint das kein besonderes Feature zu sein: Das Ausführen eines SQL Statements auf eine View lässt sich auch mit dem Data Explorer realisieren. Die Besonderheit zeigt sich erst, wenn auf einen Unterknoten in der Calculation View geklickt wird. In diesem Unterknoten ist nun auch der Debug-Query Reiter verfügbar.

Abbildung 13 – Debug Knoten

Im Hintergrund werden Views für die einzelnen Knoten generiert, welche immer der Namenskonvention „[Name der Calculation View]/dp/[Name des Knotens]“ folgen. Es können also bequem alle Teilergebnisse der Knoten selektiert und analysiert werden. Im klassischen XSC war dies nur über Umwege und Data Previews möglich, nicht aber direkt in der IDE.

Alle virtuellen Objekte haben dabei zunächst nur Zugriff auf Tabellen und Views, die im eigenen HDI Container existieren. Wie können aber Objekte selektiert werden, die in anderen HDI Containern leben? Durch die isolierte Architektur von HDI Containern ist dies nur mit neuen Artefakten und manuellem Aufwand möglich.

Cross-Access HDI Container

In diesem Abschnitt wollen wir das Vorgehen für den Zugriff auf Objekte in einem anderen HDI Container vorstellen. Zur Erinnerung: Ein HDI Container ist ein isolierter Bereich auf der Datenbank, der prinzipiell nur sich selbst kennt. Andere HDI Container und deren Objekte sind nicht sichtbar. In unserem Beispiel haben wir den Quell-HDI Container (HDI_SOURCE), der eine Tabelle aus dem Ziel-HDI Container lesen möchte (HDI_TARGET). Das folgende Schaubild zeigt den Aufbau für Cross-Access bei HDI Containern.

Abbildung 14 – Vorgehen Cross-Access

Zusammengefasst sind folgende Schritte nötig:

1. Erstellung Rollen (.hdbrole) in HDI_TARGET
2. Verbindung der HDI Container über Anpassung mta.yaml in HDI_SOURCE
3. Erstellen Grant (.hdbgrants) für Auslesen der Rollen
4. Erstellung Synonym für Quell-Objekt

Diese eher kompliziert wirkenden Vorgehensweise bedingt sich aus der Isolation der HDI Container. Der HDI Container (HDI_TARGET) muss zunächst Rollen definieren, die den Zugriff auf seine Objekte erlauben. Der Quell-Container (HDI_SOURCE) bindet diese Rollen über ein Grant-Artefakt ein. Leider ist es nicht möglich, direkt auf die Objekte zuzugreifen. Jedes Objekt benötigt ein sogenanntes Synonym, welches dann in z.B. einer Calculation View verwendet werden kann.

Ein praktischer Hinweis an dieser Stelle: Viele der Artefakte haben einen eigenen graphischen Pflegedialog. Allerdings können auch alle Dateien mit einem Rechtsklick über den Text-Editor direkt bearbeitet werden.

Abbildung 15 – Pflege in Text-Editor

Wir haben einen entsprechenden HDI mit einer Tabelle angelegt.

Abbildung 16 – Ziel-Tabelle in HDI_TARGET

Für den Zugriff erstellen wir die benötigten Rollen im Ordner roles:

Abbildung 17 – Beispiel .hdbrole ohne Grant

Abbildung 18 – Beispiel .hdbrole mit Grant

Nun stellt sich die Frage, warum zwei Rollen nötig sind. Die zweite Rolle hat im technischen Namen eine Raute (#) und vergibt Rechte mit „Grant Option“, womit die Rechte weitervergeben können. Dieses Zusammenspiel aus zwei Rollen ist technisch bedingt, da ein HDI Container aus mehreren Usern besteht. Die Rolle ohne Grant wird dem _RT User vergeben (Applikation User), der _OO (Objekt Owner) User erhält die Rolle mit Grant. Natürlich kann diese Rolle weiter eingeschränkt werden. In unserem Fall vergeben wir Lese- und Schreibrechte auf alle Objekte in dem HDI Container. Diese Rollen müssen zunächst deployed werden, bevor unser HDI Container darauf zugreifen kann.

In unserem XSA-Blog Projekt müssen nun 3 Schritte durchgeführt werden. Zuerst pflegen wir in der zentralen Steuerungsdatei (mta.yaml) den Ziel-HDI Container. Theoretisch kann dies manuell eingetragen werden, BAS bietet hier aber eine bequeme Möglichkeit in der GUI:

Abbildung 19 – Verbindung HDI Container (1/2)

Im nun geöffneten Fenster kann einfach der gewünschte HDI Container ausgewählt werden:

Abbildung 20 – Verbindung HDI Container (2/2)

Somit wird die mta.yaml Datei automatisch angepasst. Zusätzlich wird auch die .env-Datei im db-Ordner um den entsprechenden Service erweitert.

Der zweite Schritt besteht im Anlegen der Grants-Datei im „cfg“ Ordner:

Abbildung 21 – Beispiel .hdbrole

In dieser Datei werden dem Applikation User und Objekt Owner die entsprechenden Rollen zugwiesen.

Nun sind die beiden HDI Container miteinander verbunden und die nötigen Rechte und Rollen erstellt. Als dritten und letzten Schritt müssen die Synonyme gepflegt werden. Jedes Objekt, dass aus dem Ziel-HDI Container gelesen werden soll, muss in der Synonym-Datei genannt werden.

Abbildung 22 – Beispiel .hdbsynonym

Nun kann das Objekt in unserer Calculation View direkt verwendet werden.

Abbildung 23 – Synonym in Calculation View

Wie im zweiten Blog erwähnt, ergibt sich aus den isolierten HDI Containern ein größerer Fokus auf das Design. Die Entscheidung, welche Objekte in einem HDI Container sind und welche Abhängigkeiten existieren, spielt eine zentrale Rolle bei XSA. Hierzu folgende Fakten, die bei einem Design wichtig sind:

• Ein HDI Container kann nur im Ganzen (mit all seinen Objekten) deployed werden
• Quell-Objekte aus einem HDI Container haben keine Verbindung zu ihrer Verwendung als Synonyme. Ein Fehler entsteht nur im lesenden HDI Container
• Verbindungen von HDI Containern führen zu Abhängigkeiten beim Deployment, da das Objekt hinter dem Synonym immer vor dem Deployment existieren muss

Fazit

Bei dem Thema virtuelle Modellierung zeigt XSA seine volle Stärke. Durch die unterschiedlichen Artefakte können je nach Anwendungsfall und Know-How die richtigen Werkzeuge ausgesucht werden. Besonders die Calculation View besticht durch ihre Performance und Debugmöglichkeit.

Einziger Wehrmutstropfen ist die Verbindung von verschiedenen HDI Containern. Bedingt durch die isolierten HDI Container sind hier mehrere manuelle Anpassungen und diverse Artefakte nötig. Die Pflege eines Synonyms für jedes neue Objekt ist gerade bei großen Data Warehouse Applikationen hinderlich.

Im fünften und letzten Teil unserer Blogreihe befassen wir uns mit dem Thema NodeJS. Die Integration von NodeJS in XSA ermöglicht die Entwicklung von komplexen Services, die mit reinen Datenbankmitteln und SQL nicht möglich wären.