2.2 Extended Application Services Classic

Wie bereits in der Einleitung beschrieben, wurde der Bedarf an einem leichtgewichtigen Web-Anwendungsserver in Verbindung mit der HANA-Datenbank sehr früh erkannt. Dieser erweiterte Funktionsumfang der Plattform war aus zwei Gründen wichtig: Zum einen konnte die SAP auf diesem Weg zusätzliche Plattform-Funktionen, wie beispielsweise die Generierung von OData-Schnittstellen, direkt auf dem Datenbanksystem zur Verfügung stellen. Zum anderen verhalf er Kunden dazu, die Datenbank auch für Eigenentwicklungen zu nutzen, ohne weitere Infrastrukturkomponenten aufbauen zu müssen.

Mit der SAP HANA XS Engine musste kein separater Applikationsserver ergänzend zur Datenbank betrieben werden. Alle Komponenten standen in einem einzigen System und mit nur einer Installation direkt zur Verfügung.

2.2.1 XSC-Architektur

In Abbildung 2.5 erhalten Sie eine Übersicht über die Architekturen mit und ohne XS Engine.

Abbildung 2.5: Datenbankarchitektur mit und ohne integriertem Applikationsserver

Bei der Architektur ohne XS Engine (linke Seite) müssen Anwendungen mithilfe von speziellen Treibern (HANA Client Library) auf die Datenbank zugreifen.

Die XS Engine als Eigenentwicklung der SAP wurde mit dem Release HANA 1.0 SPS 05 eingeführt. Technisch betrachtet ist sie ein JavaScript-Applikationsserver, der auf der SpiderMonkey Engine von Mozilla basiert. Der XS-Engine-Prozess ist ein eigenständiger Prozess innerhalb der HANA-Datenbank, der allerdings direkt mit dem Index-Server verbunden ist.

2.2.2 XSC-basierte Softwareentwicklung

Für kundenindividuelle Entwicklungen auf der Basis von XSC kam das SAP-eigene XSJS (XS JavaScript) zum Einsatz, welches auf einer serverseitigen JavaScript-Technologie basiert. Für die Kommunikation der XSJS-Anwendung mit der Datenbank wurden diverse JavaScript-APIs angeboten. Neben der Anwendungslogik in XSJS erfolgte die Entwicklung von Benutzeroberflächen mittels SAPUI5 sowie von Datenbankfunktionen mittels SQLScript. Auf diesem Weg konnten vollständige Anwendungen basierend auf dem Softwarearchitektur-Ansatz Model View Controller entwickelt werden.

Wichtig zu erwähnen ist, dass alle Entwicklungselemente direkt im SAP HANA Repository abgelegt wurden. Da das HANA Repository ein integrierter Bestandteil des Index-Servers ist, ähnelte das Entwicklungsvorgehen dem im ABAP-Umfeld verwendeten Verfahren sehr. Der gesamte Quellcode lag in dem Laufzeitsystem und wurde nicht extern verwaltet. Die Entwicklung erfolgte mittels Web Development Workbench, einer webbasierten Entwicklungsumgebung – nicht zu verwechseln mit der neueren Web IDE, die für Entwicklungen in der XSA-Umgebung eingesetzt wird.

Seit dem Release HANA 2.0 SPS 02 werden Eigenentwicklungen auf Basis des Classic-Modells von der SAP nicht mehr empfohlen, da seit HANA 1.0 SPS 11 die XSA als Nachfolgetechnologie zur Verfügung steht. Des Weiteren hat die SAP die XSC als »deprecated« eingestuft. Das bedeutet, dass diese Komponente nicht weiterentwickelt wird und Kunden mittelfristig keinen Support mehr erhalten werden. Details hat die SAP in dem Hinweis 2465027 »Deprecation of SAP HANA extended application services, classic model and SAP HANA Repository« veröffentlicht. Eigenentwicklungen, die Kunden auf der Basis von XSC entwickelt haben, können migriert und auch weiterhin in der XSA als Node.js-Anwendung betrieben werden. Für die Migration hat SAP einen ausführlichen Migrationsleitfaden zur Verfügung gestellt.

Trotz der Empfehlung der SAP, die XSC nicht mehr für Eigenentwicklungen einzusetzen, halte ich den zuvor gegebenen Überblick auch aktuell noch für wichtig, denn gerade bei der Recherche zu HANA-Funktionen werden Sie immer wieder auf Referenzen und Anleitungen stoßen, die auf den Funktionsumfang der XSC ausgelegt sind. Nicht immer sind diese klar als solche gekennzeichnet. Für die Planung Ihrer eigenen Entwicklungen ist die technologische Grundlage ein wichtiger Aspekt, um zu entscheiden, ob eine bestimmte Komponente verwendet werden sollte oder nicht.

2.2.3 Praxisbeispiel: Eigenentwicklung mit den Extended Application Services

Die Strategie des integrierten Applikationsservers innerhalb der Datenbankplattform wurde vom Markt sehr gut angenommen. Viele SAP-Kunden mussten sich zwangsläufig, der SAP-Datenbankstrategie folgend, mit dem Thema »HANA-Datenbank« näher befassen und begannen, diese als Datenbank für die Business-Suite-Systeme in ihre Landschaft einzubinden. Da sie mit ihren integrierten Engines gleichzeitig für Entwicklungen außerhalb des ABAP-Stacks von Interesse war, beschäftigten sich zunehmend auch die Entwicklungsteams mit der HANA-Technologie.

An dieser Stelle möchte ich Ihnen ein Beispiel aus der Praxis geben, das den Mehrwert der Extended Application Services verdeutlicht:

Ein Entwicklerteam wurde mit der Spezifikation einer Anwendung beauftragt, die geografische Aspekte mit verschiedenen Geschäftskennzahlen in Verbindung setzen sollte. Das Team begann damit, eine passende Lösung für die Problemstellung zu suchen. Da die Kennzahlen in einem SAP-System lagen, bei dem die Daten bereits auf die HANA-DB migriert waren, wurde zunächst eine Schnittstelle zur Anbindung dieser Daten spezifiziert. Bei den Diskussionen zu dieser Schnittstelle kam heraus, dass die HANA-Datenbank nicht nur bereits alle benötigten Kennzahlen beinhaltete, sondern alternativ auch für die Verknüpfung mit den geografischen Daten verwendet werden konnte. Daraufhin wurde der Funktionsumfang der Spatial Engine der HANA-Plattform genauer analysiert, und die Experten waren mit den Analyseergebnissen sehr zufrieden. Also hatte man bereits zwei Bausteine der Lösung, die innerhalb der HANA-Datenbank abgebildet werden konnten.

Anschließend wurde die Frage betrachtet, ob man nicht die XS Engine nutzen könne, um die zusätzlich benötigte Anwendungslogik zu implementieren. Da bei der Analyse keine Showstopper gefunden wurden, entschieden sich die Projektmitglieder, die Entwicklung der Anwendungslogik auf dieser Engine durchzuführen. Die beauftragte Anwendung wurde also komplett als native HANA-Applikation entwickelt – und erfüllte ihren Zweck. Allerdings war die ausschließliche Nutzung von XSJS für die Anwendungslogik nicht ganz optimal. Dies hatte folgende Gründe:

• Zu Beginn des Projekts gab es niemanden, der sich mit der XSJS-Sprache gut auskannte. Die Entwickler waren entweder Experten in Spatial-Themen oder kannten sich eher mit Java oder ABAP aus.
  Da das Team klein war, wurde nach der Methode »Learning by doing« begonnen. Nach dem einen oder anderen Stolperstein wurde auch der mit der XS Engine entwickelte Teil der Anwendung erfolgreich umgesetzt. Aber die Entwicklung dauerte länger, da das fehlende Know-how erst aufgebaut werden musste.
• Die XS Engine war zu eng mit den HANA-Prozessen verwoben. Abstürze der Anwendung konnten zur Folge haben, dass das gesamte HANA-System in Mitleidenschaft gezogen wurde. Zusätzlich konnte die XS-Classic-Umgebung nicht unabhängig von den HANA-Prozessen skaliert werden. Eine Skalierung hätte den gesamten Stack betroffen, also auch die übrigen HANA-Prozesse. Wünschenswert wäre eine unabhängige Skalierung der XS Engine gewesen.

Neben diesen Hauptkritikpunkten zur XS Engine wurden noch zwei weitere Aspekte angeführt:

• Es arbeiteten noch andere Entwicklungsprojekte auf derselben Engine. Die Projekte konnten daher zur Laufzeit nicht entkoppelt werden.
• Wenn mehr als ein Entwickler eine Datei editieren wollte, kam es immer wieder zu Problemen. Daher wurde der Entwicklungsprozess innerhalb der Teams kritisiert.

Das abschließende Projektfeedback fiel trotz der Kritikpunkte sehr gut aus. Der direkte Zugriff auf die Kennzahlen und die leicht zu nutzende Spatial Engine wurden als sehr positiv angesehen. Nur die Umsetzung des integrierten Applikationsservers wurde aus den zuvor genannten Gründen bemängelt.

So oder so ähnlich haben vermutlich viele Kunden ihre Erfahrungen gesammelt und der SAP mitgeteilt.

Das Unternehmen reagierte und veröffentlichte mit der HANA-Version 1.0 SPS 11 die erste Fassung der XS Advanced (XSA). Mit dieser Anpassung wurde nicht nur ein Update für die XS-Umgebung ausgerollt, sondern ein Richtungswechsel vollzogen. Im Vergleich zu ihrem klassischen Vorgänger zeigte sich die XS Engine in der »Advanced«-Variante als komplett neue und vollumfängliche Applikationsplattform. Zudem endete der Weg einer eigenen JavaScript-Sprache. Anstelle von XSJS wurde nun ein umfangreiches Set an Sprachen unterstützt.