Sie verwenden keine aktuelle Browser-Version. Deshalb wird die Webseite möglicherweise nicht korrekt dargestellt. Hier finden Sie weitere Hinweise.

XSA NodeJS

Inhaltsverzeichnis

Im fünften und letzten Teil unserer XSA-Blogreihe beleuchten wir das spannende Thema NodeJS. Welche Funktionen bietet NodeJS unter XSA? Wie können bestehende Modelle erweitert werden? Wann und warum sollte NodeJS bei nativen HANA Modellen verwendet werden? Mit unserem Beispielmodell beantworten wir diese und mehr Fragen.

Grundlagen NodeJS

Wir haben einen langen Weg hinter uns. Gestartet sind wir im ersten Blog mit den Grundlagen, die persistente und virtuelle Modellierung wurden in den Blogs Zwei und Vier behandelt. Das komplexe Thema der Datenbeladung wurde im Detail im dritten Teil thematisiert.

Im ersten Blog haben wir bereits gesehen, dass HANA XSA aus weit mehr Services besteht, als es bei der klassischen XSC Umgebung der Fall war. Eine zentrale Komponente nimmt dabei NodeJS ein.

Abbildung 1 – Architektur XSA Umgebung

Es sei erwähnt, dass auch Applikationen mit Python und Java nativ in der XSA Umgebung laufen können. Gerade für Services wie OData bietet JavaScript allerdings einen hohen Funktionsumfang, welcher sich weltweit bewährt. Daher gehen wir an dieser Stelle nicht weiter auf die beiden anderen Programmiersprachen ein.

Aber wozu wird noch NodeJS benötigt, wenn wir alle Daten modelliert, geladen und auch virtualisiert haben? Bevor wir diese Frage beantworten, sollten wir uns zunächst ein paar Grundlagen für NodeJS anschauen.

NodeJS ist eine eigenständige Runtime und ermöglicht das Ausführen von JavaScript außerhalb von HTML-Dateien. Mit NodeJS sind wir in der Lage, einen eigenen Server zu starten und können dort auf Anfragen reagieren und Daten weiterverarbeiten. Das Starten des Servers übernimmt dabei die HANA Plattform. Simpel ausgedrückt wird für uns ein Server erstellt, der direkt auf der HANA Plattform läuft und auf Anfragen reagiert.

Damit alles etwas klarer wird, schauen wir uns ein kleines Beispiel an. Dabei gehen wir weiter auf unser erstelltes Beispielprojekt im BAS ein.

Starten eines OData Services

Ein entsprechendes NodeJS Modul wurde bereits hinzugefügt, als wir das CAP-Projekt ursprünglich über den Wizard angelegt haben:

Abbildung 2 – NodeJS Modul

Dadurch wird ein „srv“ Ordner erstellt, in dem wir nun eine neue „service.cds“. Datei erstellen. Diese beinhaltet einen minimalen Service und gibt an, welche Tabellen und Views dafür bereitgestellt werden sollen. In dieser Datei beziehen wir uns auf unsere „schema.cds“-Datei im „db“ Ordner, welche unser CDS Modell beinhaltet.

Abbildung 3 – Erstellung OData Service

Es ist zu sehen, dass die Service-Definition sehr simpel ist. Neben den Entitäten wird der Name des Services spezifiziert. Damit der Service auch funktioniert, muss zuerst der Build Prozess über den Terminal-Befehl „cds build“ gestartet werden. Dieser ist nötig, da für den Service eigene Views generiert werden. Diese befinden sich, wie auch die anderen Artefakte, in dem „db.src.gen“ Ordner:

Abbildung 4 – Generierte Service-Views

Es ist leicht zu sehen, dass wesentlich mehr Views als unsere 3 spezifizierten Entitäten generiert werden. Das liegt an unserem verwendeten CDS Modell. Durch die Assoziationen erkennt das System, dass Absprünge auf die verbundenen Dimensionen möglich sind, sodass diese Views auch benötigt werden.

Wir können den Service nun direkt über den Konsolen-Befehl „cds serve“ starten. Das BAS bietet über die NPM-Skripts-Sektion die Möglichkeit das hinterlegte start-Skript direkt auszuführen.

Abbildung 5 – Start npm Skript

Durch die Ausführung des Services wird der Server gestartet und ein Pop-Up Fenster ermöglicht die direkte Navigation dorthin:

Abbildung 6 – Service startet

Auf dem Link werden wir von der Standardansicht begrüßt und können die entsprechenden Services sehen:

Abbildung 7 – OData Service

Mit einem Klick auf eine der Entitäten, werden uns direkt die Daten im JSON-Format zur Verfügung gestellt.

Abbildung 8 – Rückgabe Headers

Da es sich bei dem Service um einen OData Service handelt, können wir die entsprechende Filterung und Navigation in der URL verwenden.

So können wir z.B. mit dem URL-Zusatz „expand“ die entsprechenden Dimensionen aufklappen.

Abbildung 9 – Navigieren über Assoziationen

Oder über „$select“ auf spezielle Spalten der Dimensionen einschränken:

Abbildung 10 – Projektionen

Es sollte an dieser Stelle gesagt sein, dass diese Navigation auf verbundene Entitäten nur möglich ist, weil wir unser Modell basierend auf CDS erstellt haben. Genau über diese gepflegten Assoziationen sind die Absprünge möglich.

Doch wie können in einem Service Entitäten angeboten werden, die nicht über CDS erstellt wurden, wie z.B. Calculation Views? Dieses Thema schauen wir uns im folgenden Kapitel an.

Service auf Datenbankartefakten

Damit schon erstellte Datenbankartefakte von einem NodeJS Service erkannt werden können, müssen diese dem Service bekannt gemacht werden. Hier legen wir eine neue Datei im „db/src“ Ordner an: persistence.cds. Der Name ist hier frei wählbar. In dieser Datei müssen wir dann die Definition der Tabelle/View/Calculation View angeben, mit der zusätzlichen Annotation „@cds.persistence.exists“. Diese sagt dem System, dass das Objekt schon vorhanden ist und nicht erneut angelegt werden muss.

Hierbei ist wichtig, dass jede Spalte korrekt mit ihrem korrespondieren Datentyp angegeben wird. Damit dies nicht per Hand gemacht wird, bietet SAP in der HANA-CLI eine Funktion, die das übernimmt. In unserem Fall wollen wir die Calculation View CVC_BILL anbinden. Der entsprechende Terminalbefehl ist „hana-cli inspectView XSA_BLOG_1 CVC_BILL -o cds“. Es gibt auch einen entsprechenden inspectTable Befehl. Das Ergebnis in der Konsole ist:

Abbildung 11 – Generierte CDS Definition

Diese Ausgabe kann direkt in die „persistence.cds“ Datei kopiert werden. In der „service.cds“ können wir nun die neue Datei anbinden und auch die Calcualtion View direkt ansprechen. Entsprechend müssen wir auch wieder die CDS Artefakte bauen und deployen.

Abbildung 12 – Service Erweiterung

Wenn wir den Service starten, können wir nun auf das Objekt zugreifen.

Abbildung 13 – Datenrückgabe Calculation View

Verarbeiten der Daten über NodeJS

Die Daten per OData anzubieten ist eine schöne Funktion von CAP, doch es gibt noch wesentlich mehr Funktionalitäten, die mit NodeJS realisierbar sind. CAP bietet hier APIs und Events an, um direkt auf die Daten zuzugreifen. Die Details würden diesen Blog sprengen, aber es ist möglich den Service um eigene JavaScript Logik zu erweitern. Dafür wird in der Definition auf eine entsprechende JavaScript-Datei verwiesen.

Eine minimale Service-Implementierung sei hier beispielhaft gegeben.

Abbildung 14 – Beispiel NodeJS Service

Was passiert in dem oberen Service? Zum einen folgen wir an dieser Stelle der Dokumentation von CAP für die Erweiterung eines Services. Innerhalb der init() Methode können wir nun eigenen JavaScript-Code ausführen, wobei wir über das cds-Paket diverse Funktionalitäten bekommen, um mit der Datenbank zu interagieren. Über „this.after“ können wir auf die Events reagieren, die automatisch vom Service geworfen werden, nachdem eine der Entitäten gelesen wurde.

In unserem obigen Beispiel hängen wir uns an das Event „READ“ mit der Einschränkung auf die Entität Headers. Somit wird unser „console.log(req)“ Befehl nur ausgeführt, wenn wir auf die Header-Daten zugreifen. Die Ausgabe können wir im BAS sehen.

Abbildung 15 – Ausgabe Terminal

Über CAP sind viele Standardschnittstellen vorgesehen, mit denen auf Daten zugegriffen werden kann und diese weiterverarbeitet werden können. Es sollte klar sein, dass alle Funktionen mit JavaScript an dieser Stelle möglich sind. Jegliche Interaktion mit der Datenbank (Lesen, Schreiben, Datenprozeduren ausführen) sind möglich und können mit Events ausgeführt werden.

Fazit

Es ist geschafft. Mit NodeJS haben wir das letzte große Puzzleteil von XSA gesetzt und es ergibt sich nun ein Gesamtbild der neuen HANA nativen Umgebung. Über die eingebaute JavaScript Umgebung lassen sich bequem Services starten und Datenbankfunktionen aufrufen, welche per Requests gesteuert werden können.

SAP bietet mit HANA XSA eine moderne Plattform mit vielen eingebauten Funktionen und Customizing-Möglichkeiten. Der Einstieg in die neuen Paradigmen ist herausfordernd, doch wir hoffen mit dieser Blogreihe den Einstieg erleichtern zu können.

Nehmen Sie Kontakt zu uns auf!

    Mit der Erhebung, Verarbeitung und Nutzung meiner personenbezogenen Daten zur Bearbeitung meiner Anfrage erkläre ich mich einverstanden. Ich kann mein Einverständnis jederzeit ohne Angabe von Gründen widerrufen. Weitere Informationen finden Sie in unserer Datenschutzerklärung.