Kitabı oku: «Cloud-Entwicklung in SAP HANA», sayfa 3

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.

SAP-XS-Migrationsleitfaden

Sie finden den Leitfaden im SAP Help Portal https://help.sap.com/ durch Eingabe des Titels »SAP HANA XS Advanced Migration Guide« im Suchfeld der Startseite.

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.

XSC-Komponente SAP HANA Rules Framework

Dieses noch heute verfügbare Framework zur Erstellung und Ausführung von Geschäftsregeln wurde auf der Basis von XSC entwickelt. Die SAP verzichtete auf eine Neuentwicklung basierend auf XSA, da bereits ein cloudbasiertes Tool der SAP existiert (SAP Business Rules Service), das für diesen Zweck genutzt werden kann. Für die XSA wird lediglich eine Komponente zur Verfügung gestellt, die den Cloud-Service referenziert. Einen Einsatz des HANA Rules Framework auf der Basis von XSC sollten Sie gut abwägen, denn es gibt weder eine Weiterentwicklung noch einen langfristigen Support.

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.

2.3 Extended Application Services Advanced

Wie im Abschnitt 2.2 dargestellt, war der grundsätzliche Ansatz der Extended Application Services eine große Bereicherung für die Arbeit auf der HANA-Plattform. Mit der Eigenentwicklung der XSC konnte die SAP den Kunden aber nicht ausreichend Flexibilität und Stabilität garantieren, damit diese Plattform auch für große Geschäftsanwendungen einsetzbar gewesen wäre. Wie in dem zuvor beschriebenen Praxisbeispiel ließen sich auf diesem Weg eher kleinere Anwendungen umsetzen.

Um noch besser zu verdeutlichen, warum die SAP die XSA als Ablösung der XSC eingeführt hat, möchte ich Ihnen zunächst das Thema »Cloud Foundry« näher beschreiben. Denn vom Grundsatz her ist die XSA eine standardisierte Cloud-Foundry-Umgebung, die in einem lokalen Rechenzentrum, also on-Premise, als Ergänzung zur HANA-Datenbank installiert wird. An einigen Stellen hat die SAP Anpassungen und Ergänzungen für die XSA implementiert. Auf diese werde ich in den folgenden Abschnitten näher eingehen.

Die Tatsache, dass der neue Applikationsserver der HANA-Plattform auf einer Cloud-Technologie basiert, ist von großer Bedeutung für Ihre Entwicklungsprojekte. Bei neuen Softwarevorhaben sollte grundsätzlich sichergestellt sein, dass alle von Ihnen verwendeten Technologien zukunftsfähig sind. Da das Thema »Cloud Computing« in der IT-Strategie vieler Firmen mittlerweile einen sehr hohen Stellenwert einnimmt, gilt dies insbesondere auch für Ihre Softwarearchitektur. Selbst wenn Sie sich zum Zeitpunkt der Entwicklung noch gegen eine Cloud-Bereitstellung entscheiden, so sollte ein späterer Wechsel möglich sein. Die Entwicklungen, die Sie mit der XSA durchführen, lassen sich vom Grundsatz her auch in der SAP Business Technology Platform – Cloud Foundry bereitstellen. Diesbezüglich wird von einer Multi-Deployment-Fähigkeit gesprochen.

Neuer Produktname für die Cloud-Plattform der SAP

Im Januar 2021 wurde von der SAP der Produktname »Business Technology Platform« eingeführt und ersetzt den zuvor für die Plattform bekannten Namen »SAP Cloud Platform«.

2.3.1 Cloud Foundry

Cloud Foundry (CF) ist eine quelloffene Entwicklungsplattform für cloudbasierte Anwendungen. Sie wurde ursprünglich in einem internen Projekt bei VMware konzipiert und 2011 unter dem Namen »Cloud Foundry« veröffentlicht. Im Jahr 2013 wurde die Software an Pivotal (ein von VMware und EMC gegründetes Unternehmen) übergeben. Seit 2015 liegen Source Code und Markenrechte von Cloud Foundry bei der Cloud Foundry Foundation. Unterstützt und weiterentwickelt wird die Plattform von diversen Unternehmen. Aktuell zählen die folgenden Firmen zu den Platin-Partnern: Dell EMC, Google, IBM, SAP, SUSE und VMware.

Cloud Foundry wird auch als »multi-cloud application platform as a service« bezeichnet. Dies bedeutet, dass Cloud Foundry in verschiedenen cloudbasierten Umgebungen genutzt werden kann und einen Platform-as-a-Service-(PaaS-)Dienst zur Verfügung stellt. Auch die SAP implementiert einen eigenen Cloud-Foundry-Dienst in der SAP Business Technology Platform.

Um besser zu verstehen, was es bedeutet, einen PaaS-Service bereitzustellen oder zu nutzen, möchte ich Ihnen kurz die aktuell gängigen cloudbasierten Servicemodelle vorstellen.

Grundsätzlich werden die folgenden Modelle eingesetzt:

 Software as a Service (SaaS)

 Platform as a Service (PaaS)

 Infrastructure as a Service (Iaas)

Diese drei Modelle unterscheiden sich vom klassischen On-Premise-Modell in der Verantwortung für die verschiedenen Komponenten. Abbildung 2.6 zeigt, welcher Funktionsumfang von einem Cloud-Anbieter verwaltet wird und welche Komponenten der Kunde bei den entsprechenden Modellen selbst verwalten kann.

Abbildung 2.6: Cloudbasierte Servicemodelle

Wie bereits beschrieben, ist Cloud Foundry ein PaaS, auf dem Sie Enterprise-Anwendungen entwickeln können. In einer CF-Umgebung können Sie also alle Daten und Anwendungen selbst verwalten. Um den darunterliegenden Technologie-Stack müssen Sie sich bei der Entwicklung Ihrer Anwendungen nicht kümmern.

Um die Vorteile von Cloud Foundry bzw. einer PaaS-Umgebung optimal zu nutzen, sind zwei Grundsätze für die Entwicklungsprojekte von Bedeutung:

 DevOps – Entwicklungsprojekte sollten mittels DevOps organisiert werden. Verallgemeinert bedeutet DevOps, dass ein Entwicklungsteam die Software nicht nur entwickelt, sondern den gesamten Lebenszyklus bis zur Produktion selbstorganisiert begleitet. Eine PaaS-Plattform unterstützt dieses Vorgehen mit einer Vielzahl an Tools.

 Zwölf-Faktoren-App – Anwendungen sollten auf speziellen, cloud-optimierten Paradigmen wie der Zwölf-Faktoren-App entwickelt werden.

Beide Grundsätze werden im Kapitel 3 dieses Buches detailliert beschrieben.

In welcher Cloud der PaaS-Dienst ausgeführt wird oder ob er sogar on-Premise als XSA läuft, ist nicht relevant. Die PaaS-Grundsätze sind in allen Varianten enthalten. Der jeweilige Funktionsumfang kann sich je nach Umgebung unterscheiden. An dieser Stelle wird der strategische Ansatz der SAP deutlich. Es wurde nicht versucht, eine eigene PaaS-Lösung zu entwickeln, sondern die SAP hat die Gestaltung und Weiterentwicklung der Cloud Foundry Platform als Platin-Partner unterstützt und diese Plattform in die eigenen Cloud- und On-Premise-Produkte (SAP Business Technology Platform – Cloud Foundry und SAP HANA XSA) eingebunden.

Da es in diesem Buch nicht um eine umfassende Beschreibung der Cloud Foundry, sondern um die Entwicklung auf der XSA geht, werde mich an dieser Stelle auf die Konzepte der Cloud Foundry Platform fokussieren, die auch in der XSA-Umgebung von großer Bedeutung sind:

 Organisationen und Spaces

 Buildpacks und Runtimes

 Skalierung von Anwendungen

Organisationen und Spaces

Ein wesentlicher Aspekt eines PaaS ist die Nutzung ebendieser Plattform für eine Vielzahl von Anwendungen und Szenarien. Das bedeutet, dass die einzelnen Anwendungen jeweils isoliert voneinander betrieben werden müssen.

Für die Isolation der Anwendungen wird eine Cloud-Foundry-Installation in mehrere logische Umgebungen aufgeteilt, die wiederum für unterschiedliche Zwecke verwendet werden können. Diese Bereiche werden als Organisationen und Spaces bezeichnet. Auf dieser Aufteilung basiert auch das Berechtigungskonzept für Entwickler, Manager und Administratoren der CF-Plattform. Deren Berechtigungen können entweder auf der Space- oder der Organisationsebene vergeben werden.

Eine CF-Instanz besteht aus einer oder mehreren Organisationen. Jede Organisation kann wiederum einen oder verschiedene Spaces beinhalten. Die Anwendungen werden in den Spaces bereitgestellt. Aufgrund der CF-Isolierung kann eine Anwendung je Space nur einmal ausgeführt werden. Wenn Sie die Anwendung mehrfach ausführen möchten, ist dies in einem weiteren Space möglich. Davon ausgenommen ist die Möglichkeit, die Anwendung zu skalieren. Dieses Verfahren wird im Abschnitt »Skalierung von Anwendungen« beschrieben.

Zugriff auf Elemente außerhalb des eigenen Space

Der Zugriff einer Anwendung auf ein Element außerhalb des eigenen Space ist grundsätzlich möglich, muss aber explizit eingerichtet werden.

Abbildung 2.7 zeigt die Beziehung zwischen den Elementen einer Cloud-Foundry-Plattform.

Abbildung 2.7: Organisationen und Spaces in CF

Die ebenfalls dargestellten Service-Instanzen werden innerhalb eines Space für die Anwendungen zur Verfügung gestellt und mittels Service-Binding mit den Anwendungen verbunden.

Eine mögliche Anwendung des Konzepts der logischen Umgebungen ist der Einsatz von Spaces für einzelne Staging-Umgebungen einer Anwendung: also einen für die Entwicklung, einen für Tests und einen für die produktive Umgebung. Alternativ können Sie verschiedene Spaces für unterschiedliche Anwendungen einsetzen und auf diesem Weg eine zusätzliche Trennung herbeiführen. Bei der Entscheidung für eine passende Nutzungsvariante sind Sie nicht festgelegt. Sie können entsprechend Ihren Anforderungen die für Sie beste Variante wählen.

Das dargestellte Modell ist dem des Mandanten-Modells eines SAP-ERP-Systems sehr ähnlich. Die einzelnen Mandanten (analog CF-Spaces) sind unabhängig voneinander, und es existieren auch mandantenübergreifende Konfigurationen (ähnlich der CF-Organisation), die systemweit gelten. Bei diesem Vergleich müssten allerdings mehrere ERP-Systeme installiert werden, um auch diverse CF-Organisationen abzubilden.

In einer Cloud-Foundry-Architektur, bei der die einzelnen Anwendungen isoliert voneinander laufen, ist die Trennung der Anwendungsdaten natürlich ein weiteres wichtiges Thema. Als PaaS ist Cloud Foundry grundsätzlich datenbankunabhängig. Im Kontext von Cloud Foundry wird die Datenhaltung über zentrale, cloudbasierte Datenbank-Instanzen abgedeckt, die über Service-Instanzen in einem Space zur Verfügung gestellt werden. Diese wird über ein Service-Binding mit der Anwendung verbunden. Für die XSA-Umgebung wäre dies z.B. eine HANA-Service-Instanz.

Buildpacks und Runtimes

Damit Anwendungen in Cloud Foundry ausgeführt werden können, benötigen sie eine Laufzeitumgebung (Runtime). Diese wird gemeinsam mit der Anwendung als eine Art Container auf der Plattform zur Verfügung gestellt. Die Erstellung dieser Container übernehmen die Buildpacks. Je verwendeter Programmiersprache gibt es entsprechende Buildpacks. Dadurch wird das Konzept Bring your own Language (ByoL) umgesetzt. Dieses ermöglicht den Einsatz diverser Programmiersprachen innerhalb der Plattform. So können Sie beispielsweise Ihre Anwendung mit Java, Go, Ruby, PHP, Node.js oder weiteren Programmiersprachen entwickeln.

Buildpacks der Cloud Foundry Community

Eine aktuelle Liste der von der Cloud Foundry Community bereitgestellten Buildpacks finden Sie auf der Internetseite https://docs.cloudfoundry.org/buildpacks/.

Die dort aufgeführte Liste ist jedoch nicht vollständig.

Als Entwickler haben Sie zudem die Möglichkeit, eigene Buildpacks nach Ihren Wünschen zu entwickeln. Im Internet finden Sie diverse Beispiele und Implementierungen, die Sie entweder nachbauen oder direkt verwenden können. Diese zusätzlichen Buildpacks sind allerdings im Vergleich zu den offiziellen Community Buildpacks nicht übergreifend getestet und validiert. Es ist also Vorsicht geboten, wenn diese für produktive Zwecke eingesetzt werden sollen.

CF Community Buildpacks in der XSA

An dieser Stelle möchte ich Sie darauf hinweisen, dass die SAP nicht alle CF-Buildpacks in der XSA bereitstellt. Dort sind aktuell nur die Buildpacks für Java, Node.js und Python zu finden.

Alle weiteren Buildpacks (auch Eigenentwicklungen) können grundsätzlich integriert werden. Da die SAP in diesem Fall keinen Support übernimmt, ist es empfehlenswert, sich bei der XSA-Entwicklung auf die offiziell unterstützten Buildpacks zu beschränken.

Da Anwendungen in der Cloud Foundry Platform immer inklusive der Laufzeitumgebung zur Verfügung gestellt werden, lassen sich bestimmte Versionen und Konfigurationen durch das Buildpack festlegen. So sind diese nicht mehr außerhalb der Kontrolle des Entwicklers änderbar, selbst wenn die Plattform aktualisiert wird. Dieses Verfahren stellt sicher, dass die entwickelte Anwendung immer identisch betrieben wird.

Das Zusammenspiel zwischen Buildpack und Runtime lässt sich wie folgt verdeutlichen: Bei einer Java-Web-Anwendung wird das Java-Buildpack verwendet. Bei der Konfiguration des Buildpack sind unterschiedliche Runtimes einstellbar, die bei der Bereitstellung eingebettet werden. Je nach Anwendung wird z.B. ein Tomcat- oder TomEE-Applikationsserver in einer bestimmten Version eingebettet.

Verwendung von Runtimes in der XSA

In der XSA-Umgebung wird die Konfiguration der zu nutzenden Runtime etwas restriktiver behandelt als in der Cloud-Foundry-Umgebung. Die SAP liefert in den jeweiligen Patches passende Updates der Runtimes aus. Diese lassen sich mit den administrativen Werkzeugen konfigurieren. So können Sie beispielsweise bei Bedarf ältere Version deaktivieren.