Im zweiten Teil unserer XSA-Blogreihe widmen wir uns der persistenten Datenhaltung in der modernen HANA Platform. Wie werden Tabellen in XSA erstellt? Welche Rolle spielen dabei HANA Deployment Infrastructure (HDI) Container? Welche Vorteile bringt SAPs Cloud Application Programming Model (CAP)? Diese spannenden und essenziellen Fragen beantworten wir mit Hilfe eines Beispielprojekts, welches wir im Business Application Studio (BAS) erstellen werden.
HDI Container
Durch unseren ersten Blog wissen wir, dass mit der Einführung von XSA ein fundamentaler Paradigmenwechsel bei der Erstellung von HANA nativen Modellen vollzogen wurde. Der Ansatz eines zentralen (datenbanknahen) Systems weicht einem Cloud-fokussierten System mit getrennten Applikationen und eigenen Services. Doch wie genau sieht die Trennung der Applikationen aus?
In einem klassischen XSC HANA Modell befinden sich die Designtime Objekte (Calculation Views, Table Functions) in Paketen und die Runtime Objekte zentral in einem Schema. In der neuen XSA Welt werden die Designtime Objekte über Git verwaltet, wobei jeder Entwickler mit seiner lokalen Kopie arbeitet. Die Runtime Objekte befinden sich in HDI Containern.
Ein HDI Container ist eine Kombination aus 3 Schemas:
Jedes XSA Projekt mit einer persistenten Datenhaltung definiert (mindestens) einen HDI Container in welchem die neuen Objekte angelegt werden. Die Berechtigungen sind im Standard so vergeben, dass ein HDI Container nur sich selbst kennt und andere HDI Container nicht sieht und damit keinen Zugriff auf deren Daten hat; eine Folge des Ansatzes zu isolierten Applikationen. Diese Verbindung muss bei Bedarf manuell erstellt werden.
Dabei arbeitet zunächst jeder Entwickler mit seinen eigenen HDI Containern: Im Standard werden die HDI Container um ein aufsteigend nummeriertes Suffix ergänzt, z.B. MY_HDI_1. Durch den Build der einzelnen Artefakte werden diese in der persönlichen Kopie erstellt und können isoliert entwickelt und getestet werden. Erst beim Deployen des gesamten Projekts wird der eigentliche HDI Container angepasst.
Dabei ist es wichtig zu verstehen, dass beim Deployment (nach den Entwicklungen) das Projekt (als Applikation) eine Einheit darstellt. Alle Objekte in einem HDI Container werden in ihrer Gesamtheit deployed, die Beschränkung auf einzelne Artefakte ist dabei nicht möglich. Grundsätzlich prüft das System, ob ein Artefakt angepasst wurde und verändert im Idealfall nur die betroffenen Runtime Objekte.
Durch die isolierte Struktur der HDI Container empfiehlt es sich nicht, diese zu kleinteilig aufzubauen. Die Kommunikation mit anderen Containern benötigt ein gewisses Setup und manuelle Pflege (Rollen, Grants, Synonyme). Zusätzlich bedingen bestimmte Artefakte wie z.B. Trigger eine Abhängigkeit der Artefakte beim Deployment, sodass diese nicht beliebigen Containern zugeordnet werden können. In vergangen Projekten hat es sich empfohlen, die benötigten Tabellen und auch die Objekte für die Datenbeladung (Prozeduren, Flowgraphen) in einem Container zu bündeln.
Persistenz und CAP
Für die Persistenz in XSA ist ein Artefakt zuständig: .hdbtable. Dabei handelt es sich um einen SQL „CREATE“ Befehl für eine Datenbanktabelle. Mit diesem Artefakt werden beim Build bzw. Deploy Prozess die entsprechenden Tabellen im HDI Container erstellt oder angepasst.
Im Hintergrund von XSA ist NodeJS mit JavaScript für die Verwaltung der HDI Container und Artefakte zuständig. Vergleichbar ist dies mit der integralen Rolle von ABAP in z.B. einem S/4HANA oder BW/4HANA System. Wie für NodeJS typisch, werden die einzelnen Dateien in NPM Packages verwaltet. NPM kann als zentrale Bibliothek für wiederverwendbare JavaScript Programme gesehen werden.
Ein XSA Projekt ist daher eigentlich ein neues NPM Package, eingerichtet mit Packages für die Erstellung und Verwaltung der HDI Container, Services und Artefakte. Alle relevanten Befehle können dabei direkt über die Konsole im Business Application Studio (BAS) eingegeben werden. Viele häufig verwendeten Tätigkeiten werden jedoch bereits über die GUI angeboten.
An dieser Stelle kommt das Cloud Application Programming Model (CAP) zum Einsatz. Dabei handelt es sich um ein Framework aus Programmiersprachen, Libraries und Tools für die Erstellung von Services und Modellen. Der Fokus liegt dabei nicht in technischen Details, sondern in der Absicht was das Modell und die Entitäten aussagen sollen, sowie das Verhalten bei Veränderungen. Für ein persistentes Modell bietet das CAP die Core Data Services (CDS).
Kurz zusammengefasst bietet CDS die Möglichkeit, Entitäten zu modellieren, wobei sogenannte Assoziationen und Kompositionen die Beziehungen zwischen den Entitäten darstellen. CDS bietet dabei noch wesentlich mehr Aspekte. An dieser Stelle fokussieren wir uns aber auf die Definition von persistenten Strukturen.
Bei der Erstellung von persistenten Objekten in XSA gibt es zwei Möglichkeiten: Die direkte Erstellung von .hdbtable Dateien, welche nah an SQL sind und klassischen Datenbankmodellierungen entsprechen. Die andere Möglichkeit ist die Verwendung von .cds-Dateien, die mit CDS und CAP arbeiten. Durch den Befehl „cds build“ werden diese dann in .hdbtable-Dateien umgewandelt und können deployed werden.
Wie so oft haben beide Ansätze ihre Vor- und Nachteile. Die direkte Erstellung von .hdbtable-Dateien arbeitet mehr auf der Datenbankebene und offeriert einen sehr technischen Fokus bei der Modellierung. Über CDS hingegen kann mehr Semantik in das Modell gebracht werden, welche über einen OData Service ausgelesen werden kann.
Zu besseren Einordnung der vielen neuen Begriffe und Konzepte veranschaulichen wir diese in einem BAS Beispielprojekt.
Beispielprojekt – Setup
Für das Beispielprojekt wird ein BTP Account mit HANA Cloud Instanz und eingerichtetem BAS benötigt. Alle nötigen Komponenten sind Teil des BTP Trail Accounts, der kostenfrei erworben werden kann. Die Einrichtung dieser Komponenten ist nicht Bestandteil dieses Blogs, es gibt allerdings eine Vielzahl an Quellen, welche die nötigen Schritte beschreiben.
Die BAS Entwicklungsumgebung und eingebauten Packages von SAP ändern sich durch Updates im Laufe der Zeit, sodass in der Zukunft die Menus oder Befehle anders aussehen können. Über den Template Wizard haben wir zunächst ein CAP Projekt angelegt, ohne zusätzliche Dateien.
An dieser Stelle ist es sehr empfehlenswert das XSA-Projekt an ein Git Repository zu binden. Somit können im Laufe des Projekts alle Änderungen nachvollzogen werden und die Dateien können historisiert abgespeichert werden.
Für die persistenten Artefakte benötigen wir ein DB Modul, welches auf unterschiedliche Weise eingerichtet werden kann. Eine einfache Möglichkeit ist es den vorhandenen (leeren) „db“-Ordner zu löschen. Über ein Terminal kann der Befehl „cds add mta“ ausgeführt werden, sodass eine mta.yaml-Datei angelegt wird, die als zentrale Steuerungsdatei aller Module gesehen werden kann.
Mit einem Rechtsklick auf die mta.yaml-Datei können wir über einen Wizard ein DB-Modul einfügen, welches wir „db“ nennen. Zusätzlich möchten wir den Schema-Namen festlegen, was auf der nächsten Seite des Wizards möglich ist.
Wichtig ist die letzte Option, die nach dem Binden einer Service Instanz fragt. Der Begriff „Service“ ist im BTP Umfeld sehr weit gegriffen. In unserem Fall ist dieser Service der entsprechende HDI Container, der durch das DB Modul erstellt wird. Die Einrichtung eines HDI Containers und Service Keys sowie das Binden an unsere Entwicklung sind auch über Terminal Befehle möglich. Der Wizard übernimmt diese aber für uns.
Für die Verwendung von CDS benötigen wir nach der Erstellung des DB Moduls noch zwei weitere Anpassungen. Zunächst müssen wir die nötigen NPM Packages installieren. Dies wird über den Befehl „npm install“ im Root-Verzeichnis des Projekts erreicht. Zusätzlich möchten wir CDS noch etwas konfigurieren, sodass es besser zu unseren Entwicklungen passt. Hierfür fügen wir in der package.json folgende Parameter für CDS ein:
Normalerweise werden die .hdbtable-Dateien in einen eigenen „gen“-Ordner erstellt. In unserem Projekt möchten wir die generierten Dateien allerdings unterhalb des „db“-Ordners haben. Diese Veränderung wird durch die Definition des „build“-Parameters erreicht. Der untere „requires“ Befehl legt fest, dass wir .hdbtable Artefakte haben möchten. In der Vergangenheit waren auch .hdbcds-Dateien möglich.
Beispielprojekt – CDS Datenmodell
Für die Verwendung von CDS benötigen wir ein „.cds“-Artefakt. Ähnlich zu einem SQL CREATE-Befehl werden über eine eigene Syntax die Strukturen definiert. Neben klassischen Entitäten sind auch wiederverwendbare Typen oder Eigenschaften möglich. Im Gegensatz zu den .hdbtable-Dateien können wir mit CDS mehrere Tabellen in einer Datei bündeln. Daher erstellen wir zunächst eine „schema.cds“-Datei unter dem „db“-Ordner.
Für CDS bietet SAP Standard Entitäten und Definitionen an, welche wiederverwendet werden sollten. Es werden Tabellen für Sprache, Währungen oder Ländern bereitgestellt, dazu weitere Eigenschaften wie eindeutige IDs. Die Datei befindet sich im entsprechenden NPM-Package und kann über folgende Syntax ausgelesen werden.
Diese ist an das „require“ aus JavaScript angelehnt und beschreibt, welche Entitäten aus einer Datei verwendet werden. Bei größeren Modellen bietet es sich an, seine eigenen Entitäten in mehreren Dateien zu halten und diese in einer zentralen Datei zu vereinen.
Für die Struktur von Artefakten ist es üblich sogenannte „namespaces“ zu verwenden. Hierbei handelt es sich um Präfixe für die Tabellen, damit diese leichter zu identifizieren sind. Für unser Beispielmodell begnügen wir uns mit Stammdaten für Kunden und Material, sowie zwei transaktionalen Tabellen für Rechnungsköpfe und -positionen.
Wir beginnen mit den Stammdaten für Kunden und Material. An dieser Stelle können wir nicht die gesamten Grundlagen und Feinheiten von CDS erläutern, sodass wir auf ausgewählte Besonderheiten eingehen
- SAP empfiehlt die Verwendung von UUIDs als eindeutige Schlüssel
- Aspects können durch die Nennung nach dem „:“ wiederverwendet werden
- Assoziationen definieren Beziehungen zwischen den Entitäten, ähnlich zu Datenbank-Joins
- Bei Auflistungen von Merkmalen, z.B. E-Mailadressen, empfiehlt es sich Arrays zu verwenden, sodass die Inhalte als JSON-Datei abgelegt werden können
Testweise können die entsprechenden .hdbtable-Dateien über den Befehl „cds build“ im „gen“-Ordner erzeugt werden. Bei der Betrachtung der Kundendatei wird schnell klar, dass CDS viele Definitionen automatisch vergibt, abhängig von der Spezifikation.
Neben den Stammdaten wollen wir im nächsten Schritt die transaktionalen Tabellen definieren. Typen und Aspekte helfen bei der Wiederverwendung von Komponenten. Kompositionen sind ähnlich zu Assoziationen.
Nach dem Erstellen der Einträge in der schema.cds-Datei können wir über den Befehl „cds build“ die .hdbtable-Dateien generieren. Für das tatsächliche Erstellen der Tabellen im HDI Container empfiehlt sich die Verwendung der BAS GUI. Hier kann im Menu für SAP HANA Projects das Raketensymbol verwendet werden. Dadurch starten im Hintergrund die JavaScripte, welche die Definition aus den .hdbtable-Dateien nehmen und diese in Runtime Objekte auf der Datenbank umwandeln.
Nun können die Strukturen direkt auf der Datenbank geprüft werden. Hierzu kann in der BAS der integrierte HANA Database Explorer verwendet werden, oder aus der BTP der separat verfügbare Database Explorer, welcher zum aktuellen Zeitpunkt die meisten Funktionen bietet.
Allerdings fehlt, wie so häufig, ein wichtiger Aspekt des Modells: Daten. Wie Test-Daten für ein Modell einfach erstellt werden können, schauen wir uns im letzten Abschnitt dieses Blogs an.
Beispielprojekt – Daten
XSA bietet die Möglichkeit, vorhandene Tabellen simpel mit Daten zu befüllen. Hierfür wird eine csv-Datei benötigt und ein weiteres Artefakt: .hdbtabledata. In dieser Datei sind die Metadaten für den Import der Daten festgelegt: Name der csv-Datei, Name der Tabelle, Name und Reihenfolge der Spalten. Diese Dateien können wie schon die .hdbtable-Artefakte manuell erstellt werden. Aber auch hier hilft uns CDS.
Für die Datenbelieferung über CDS bedarf es nur der entsprechenden csv-Datei in einem Unterordner „csv“ direkt unter dem „db“-Ordner. Dort wird die Datei mit identischem Namen zur Tabelle angelegt und mit Daten befüllt. Für die Kunden-Tabelle sei folgendes Beispiel gegeben:
Weitere Dateien sind nicht nötig, da CDS an dieser Stelle den Rest übernimmt. Wird nun erneut der „cds build“ Befehl ausgeführt, so wird automatisch eine .hdbtabledata-Datei erstellt. Wiederum beim nächsten Deploy-Befehl wird der Inhalt der csv-Datei automatisch in die Tabelle geschrieben.
Mit dem neuesten Dezember 2022 Release von CAP stellt SAP ein neues Package zur Verfügung, welches Beispiel-Daten für die Standardtabellen enthält. Für die Verwendung in unserem Projekt binden wir das Package über „npm add @sap/cds-common-content –save“ ein. In unserer schema.cds-Datei fügen wir folgende Zeilen ein
Das führt dazu, dass bei dem nächsten Build und Deploy automatisch von der SAP bereitgestellte CSV-Dateien verwendet werden und unsere Tabellen für Länder, Währungen und Sprachen befüllt.
Ausblick
Durch die Verwendung von CDS haben wir in kurzer Zeit ein solides Modell erstellt und dieses mit Testdaten befüllt. Im nächsten Blog gehen wir der Frage nach, welche Möglichkeiten und Artefakte es für die Datenbeladung und -beschaffung in einem XSA System gibt. Dabei schauen wir uns an, was der Standard bietet und wo SQLScript gefragt ist.
Fazit
Schon der erste Blog hat gezeigt, dass XSA eine neue Welt ist. Dieser Blog hat eine Vielzahl von Begriffen eingeführt: HDI Container, .hdbtable, CAP und CDS. Auf den ersten (und vielleicht auch zweiten) Blick mag das überwältigend und abschreckend sein. Es ist aber wichtig zu verstehen, dass hier mit teilweise jahrzehntealten Methodiken und Praktiken gebrochen wird und ein wirklich modernes System angeboten wird.
Der Fokus der SAP liegt in der Cloud und Frameworks wie CAP. Die regelmäßigen Erweiterungen und Updates sprechen für sich. Wie so häufig werden komplexe Themen verständlich, sobald die Grundlagen verstanden und darauf aufgebaut wird. Mit diesem Blog möchten wir Ihnen helfen, sich in der neuen Welt zurechtzufinden.