Mit SAP HANA XSA hat die SAP ihre strategische Ausrichtung für SAP HANA festgelegt und einen klaren Fokus auf eine moderne Entwicklung mit isolierten Applikationen gelegt. Mit diesem Schritt ist klar, dass XSC und damit die Entwicklungen im HANA Studio mit Paketen und Schemas der Vergangenheit angehören.
Aber wie sieht diese neue XSA Welt aus? Was ist anders? Welche neuen Möglichkeiten ergeben sich?
In diesem ersten Teil einer mehrteiligen Blogreihe gehen wir auf die Grundlagen von HANA XSA ein und zeigen die Unterschiede zu XSC auf.
Was ist SAP HANA XSA?
Zunächst eine wichtige Information vorab: XSC, also die nativen Entwicklungen von SAP HANA Artefakten im HANA Studio ist obsolet. Sie wird nicht mehr weiterentwickelt und es werden keine neuen Features hinzukommen. Die Zukunft heißt XSA und dort steckt auch der gesamte Fokus von SAP bezüglich HANA.
SAP HANA XSA ist ein Paradigmenwechsel für die Entwicklung mit SAP HANA. Diese Aussage klingt zunächst extrem, da auf den ersten Blick der Applikationsserver im Vergleich zu XSC lediglich neue Komponenten wie NodeJS oder HTML5 erhalten hat.
Allerdings hat sich die Art der Entwicklung in XSA grundlegend geändert. Anstatt Objekte datenbanknah in Paketen oder Schemas zu entwickeln, setzt die SAP bei XSA auf isolierte Applikationen und SAP HANA Deployment Infrastructure (HDI) Container. Dieser Schritt war nötig für die Cloudfähigkeit des Systems. Durch den strategischen Fokus auf Cloud Foundry musste auch die HANA den neuen Anforderungen der isolierten Services und Anwendungen gerecht werden.
SAP HANA XSA kann sowohl in einem On-Prem System als auch mit der SAP HANA Cloud betrieben werden. Der Funktionsumfang ist nahezu identisch, größter Unterschied sind die beiden unterschiedlichen Entwicklungsumgebungen.
Business Application Studio
Wie bei neuen Technologien üblich, gibt es auch bei XSA eine neue Entwicklungsumgebung. Die SAP hat hierfür dem vorherigen Tool HANA Studio den Rücken gekehrt und geht einen modernen Schritt in Richtung der Web-basierten IDEs. Durch diese Maßnahme fällt das Ausrollen neuer oder aktualisierter IDE-Software weg, da die Entwicklungsumgebung zentral gewartet wird und direkt über den Browser erreichbar ist.
Wie bereits erwähnt kann XSA bei einem On-Prem oder Cloud Szenario eingesetzt werden, wobei die eingesetzte IDE leicht unterschiedlich ist:
- On-Prem -> SAP Web IDE for SAP HANA
- Cloud -> Business Application Studio (BAS)
In dieser Blogreihe verwenden wir ein HANA Cloud Szenario, sodass wir uns näher mit BAS beschäftigen werden.
Bei BAS handelt es sich um eine Komponente der Business Technologie Platform (BTP), wobei eine Vielzahl an Sichten und Entwicklungsmöglichkeiten angeboten werden. Ob Datenbankmodellierung mit SQLScript und Calculation Views oder Applikationen mit NodeJS: Alle verwenden BAS. Das BAS ist stark angelehnt an Visual Studio Code und arbeitet mit Plugins, die nach Belieben installiert und aktiviert werden können.
Anders als bei XSC liegt der Fokus nicht auf der direkten Entwicklung in Paketen und Datenbankschemas, sondern in eigenen Multi Target Application (MTA)-Projekten über welche HDI Container angelegt werden. Diese HDI Container funktionieren wie eine isolierte Applikation innerhalb der Datenbank.
Die Verwendung von BAS ist zunächst sehr intuitiv: Zuerst wird ein neues Projekt erstellt, wobei einzelne Module, wie z.B. Datenbank oder NodeJS, hinzugefügt werden. In einer Ordnerstruktur werden dann alle benötigten Designtime-Objekte angelegt (Calculation Views, Tabellen, Table Functions). Anschließend werden (anders als bei XSC) diese Artefakte nicht aktiviert, sondern deployed, wodurch entsprechende Datenbankobjekte erstellt werden.
HANA XSC vs. HANA XSA: Was sind die Unterschiede?
XSC lebt im SAP HANA Studio und arbeitet mit Artefakten in Paketen. Diese Artefakte sind Designtime-Objekte, für welche bei der Aktivierung entsprechende Runtime-Objekte angelegt werden. Oft werden die Artefakte „.hdbdd“ für die Modellierung von persistenten Daten in Tabellen und „.calculationview“ für die virtuelle Datenaufbereitung verwendet.
Die ausführbaren Datenbankobjekte gehören alle dem User _SYS_REPO und befinden sich im Schema _SYS_BIC. In diesem Szenario ist es sehr einfach auf Tabellen oder Calculation Views aus anderen Paketen/Schemas zuzugreifen, da alles zentral verwaltet wird und somit für andere User sichtbar ist.
Mit SAP HANA XSA gibt es weiterhin die Trennung zwischen Designtime- und Runtime-Objekten. Auch hier finden Artefakte für die persistente (.hdbcds) und virtuelle (.hdbcalculationview) Modellierung ihre Anwendung.
An dieser Stelle enden allerdings bereits die Gemeinsamkeiten der beiden Ansätze, da XSA die Trennung der Objekte komplett verschärft. Es gibt nicht mehr „die eine Wahrheit“ im Schema des Systems, wie vorher in _SYS_BIC. Jeder Entwickler sieht seine (lokale) Version der Designtime-Objekte und kann unabhängig Änderungen vornehmen und diese in sein eigenes Datenbankschema deployen.
Aber wie genau können dann die Entwicklungen mit unterschiedlichen Ständen und Developern konsistent bleiben? Die Antwort liegt in der Quellcodeverwaltung mit Git, welches eine zentrale Rolle in der Entwicklung mit XSA spielt. Das entsprechende Repository mit seinen Branches und Commits sorgt dafür, dass alle Entwicklungen konsistent bleiben.
Bei Git Repositories gibt es, vereinfacht gesehen, einen Hauptstrang (Master), in dem die aktuelle Entwicklung abgelegt wird. Für neue Features, Bugfixes oder Erweiterungen erstellen Entwickler entsprechende Stränge (Branches) und arbeiten dort mit lokalen Kopien. Sollten diese Entwicklungen abgeschlossen sein, werden sie in den Hauptstrang eingefügt (commit), wobei nur die Änderungen übernommen werden. Sollte es dabei zu Konflikten mit anderen Anpassungen kommen, können diese zentral betrachtet und bereinigt werden.
HANA XSA Vorteile
Wird also durch XSA alles komplizierter? Es mag stimmen, dass die neuen Ansätze in XSA zunächst radikal und ungewohnt erscheinen. Allerdings bieten sich dadurch auch völlig neue Potenziale, die im alten Ansatz nicht möglich waren. Auf der einen Seite gibt es in Bezug auf die Datenmodellierung und Architektur eine Vielzahl an neuen Funktionen für Calculation Views:
- Neue Knotenarten (Intersect, Minus, Non-Equi Join, Window Function)
- Debug Mode
- Performance Analysis Mode
- Outline
Andererseits gibt es eine Reihe neuer Artefakte für die Modellierung, die Standardfunktionalitäten beinhalten. Ein prominentes Beispiel sind die komplett überarbeiteten Flowgraphen, die neben Datenladeprozesse auch Knoten für Datenbereinigung und Predictive Analytics haben. Für die Datenbeschaffung (Data Provisioning) gibt es zusätzlich die Replication Tasks, welche Realtime-fähig sind.
Zusätzlich gibt es über den eingebauten NodeJS die Möglichkeit, direkt auf den definierten Objekten neue SAP Fiori Reports mit SAP UI5 zu bauen. Diese Applikationen können dann nach Bedarf auf unterschiedlichen Systemen deployed und skaliert werden.
Ausblick
Im nächsten Teil dieser Blogreihe gehen wir anhand eines Beispielprojekts auf das Anlegen von Datenbankobjekten mit BAS ein. Dabei erkunden wir neue virtuelle Modellierungsmöglichkeiten mit CalculationViews. Ein weiterer Fokus wird auf den bereits erwähnten HDI Container mit Best Practices liegen und wie diese im Projekt realisiert werden können.
Fazit
Was also ist XSA? XSA ist weit mehr als eine einfache Weiterentwicklung der bekannten Objekte und Methoden. Es ist eine neue Welt mit völlig neuen Möglichkeiten und auch Regeln. Moderne Applikationen mit Datenbankobjekten, Prozeduren, OData Services und NodeJS Applikationen sind nun in einem System möglich und ebnen den Weg in eine neue Zukunft mit modernen Konzepten und Ansätzen.