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

2 HANA-Plattform

In diesem Kapitel werde ich Ihnen die Architektur und die wichtigsten Funktionen der HANA-Plattform aufzeigen. Diese Grundlagen werden Ihnen helfen, die Plattform für Ihre eigenen Softwareprojekte optimal zu nutzen.

2.1 SAP HANA

Die SAP-Strategie, ausschließlich HANA als Datenbank für aktuelle SAP-Systeme zuzulassen und Produktinnovationen nur noch für HANA-basierte Systeme zur Verfügung zu stellen, hat den Vorteil, dass die Software nicht mehr wie früher eine Vielzahl von Datenbanksystemen unterstützen muss.

In den älteren SAP-Systemen – bis SAP ERP Central Component (ECC) 6.0 – hat der NetWeaver AS die Datenbankkommunikation gekapselt. Die Anwendung selbst brauchte die Unterschiede der Datenbanksysteme nicht zu berücksichtigen. Von der Nutzung spezieller Funktionen der einzelnen Datenbanken wurde aus technischer Sicht abgeraten, da sie bei Anpassungen des Datenbanksystems ggf. nicht mehr funktioniert hätten.

Durch die alleinige Nutzung von HANA als Datenbank können die spezifischen HANA-Funktionen aus den Anwendungen heraus vollumfänglich zum Einsatz kommen. Des Weiteren können bei der Entwicklung von Anwendungen sogar einige Teilfunktionen komplett in die HANA-Datenbank ausgelagert werden. In diesem Fall wird von einer nativen HANA-Entwicklung gesprochen.

2.1.1 In-Memory-Datenbank-Technologie

Ein weiterer Vorteil der HANA-Datenbank ist, dass sie alle relevanten Daten im Hauptspeicher, also »In-Memory«, hält. Kritiker sagen, dass dies auch andere Datenbanksysteme können. Diese Aussage stimmt natürlich, denn andere Hersteller von Datenbanken bieten ebenfalls eine In-Memory-Technologie für ihre Produkte.

Stark vereinfacht, geht es bei allen In-Memory-Datenbanken darum, die Zugriffszeiten auf die Daten zu optimieren. Auf Daten im Hauptspeicher kann deutlich schneller zugegriffen werden als auf Daten, die erst zeitintensiv von der Festplatte gelesen werden müssen.

Dauerhafte Speicherung der Daten

Auch bei In-Memory-Datenbanken werden die Daten im Arbeitsspeicher für eine dauerhafte Speicherung zusätzlich in das angebundene Dateisystem gespeichert. Dies ist notwendig, falls das System neu gestartet und dabei der Arbeitsspeicher geleert wird. Beim Systemstart der HANA werden die Daten dann wieder in den Arbeitsspeicher geladen. Dieser Prozess läuft vollautomatisch ab.

Die Stärken von SAP HANA sind allerdings nicht nur in der Datenbanktechnologie selbst zu suchen. Dass die Datenbank und die Anwendungen vom selben Hersteller stammen, bietet einen erheblichen Vorteil. Seit dem Beschluss, dass HANA zukünftig als alleinige Datenbank für SAP-Systeme verwendet werden soll, optimiert die SAP ihre Anwendungen Schritt für Schritt für eine Nutzung mit dieser Datenbanktechnologie. Dabei ist sie nicht mehr von den Funktionsangeboten anderer Datenbankanbieter abhängig.

Bei der von der SAP verfolgten HANA-optimierten Entwicklung spricht man vom Code Pushdown. Dessen Ziel ist es, Datenoperationen nicht mehr in einem Anwendungsserver durchzuführen, sondern direkt in der Datenbank. Die Programmlogik wird also in die Datenbank verlagert bzw. »gepushed«. Abbildung 2.1 stellt die Logik des Code Pushdown exemplarisch dar.

Abbildung 2.1: Anwendungen mit und ohne »Code Pushdown«

Anwendung 1 lädt die Datensätze 1 und 2 aus der Datenbank und führt die programmierte Logik auf diesen Daten aus. Gerade bei großen Datenmengen kann das Laden der Daten in den Applikationsserver einige Zeit in Anspruch nehmen.

Im Gegensatz dazu basiert Anwendung 2 auf dem Prinzip des Code Pushdown. Hier wird die Logik in der Datenbank selbst ausgeführt. Da dort alle Daten im Hauptspeicher gehalten werden, kann die Datenbank das Ergebnis schnell an die Anwendung zurückliefern.

Dieses Prinzip wird in allen modernen SAP-Produkten eingesetzt, um Datenoperationen zu optimieren.

2.1.2 Spalten- und zeilenorientierte Datenspeicherung

Neben der In-Memory-Technologie ist für Ihre Projekte noch ein weiterer Aspekt relevant, der dem besseren Verständnis für eine Nutzung der HANA-Datenbank-Technologie dient. Dies ist die Verwendung der spaltenorientierten (Column Store) oder zeilenorientierten Ablage (Row Store) der Tabellendaten.

Weitere spaltenorientierte Datenbanksysteme

Auch andere Hersteller, wie z.B. Oracle (12c mit In-Memory-Option) und Microsoft (SQL-Server 2012 mit dem Column Store Index Feature), bieten in ihren Produkten verschiedene Ablageoptionen. Die Technologie ist also nicht SAP- oder HANA-spezifisch.

Nachfolgend werde ich diese beiden Technologien kurz beschreiben und Ihnen die jeweiligen Vor- und Nachteile aufzeigen.

In der Vergangenheit haben die gängigsten Datenbanksysteme die Daten der Tabellen zeilenorientiert behandelt. Dabei erfolgen sowohl die Datenablage als auch der Zugriff auf die Daten zeilenweise. Im Gegensatz dazu steht die spaltenorientierte Organisation der abgelegten Daten. In der HANA-Datenbank kann sich der Entwickler je Tabelle entscheiden, welche der beiden Ablagemöglichkeiten er verwenden möchte; beide Verfahren werden unterstützt.

Um den Unterschied zwischen beiden Varianten zu verstehen, nehmen wir eine einfache Tabelle zu Hilfe. Diese betrachten wir zunächst als logische Struktur (Abbildung 2.2), wie wir sie beispielsweise aus Excel oder anderen Tabellenkalkulationstools kennen.

Abbildung 2.2: HANA-Tabelle – logische Struktur

Die Daten zur Einwohnerzahl rechts in der Tabelle sind vom Dezember 2019 [1]. Für unser Beispiel sind allerdings nicht die Daten an sich von Interesse, sondern die Art und Weise, wie diese in der Datenbank abgelegt werden. Die logische Struktur ist zweidimensional, die Ablage muss aber in eindimensionaler Form erfolgen.

Stellen wir uns die physikalische Ablage der Tabelleninhalte als eine Aneinanderreihung von Blöcken vor, bei dem jeder Block den Wert von genau einer Zelle aufnehmen kann.

Die oben gezeigte Tabelle wird bei einer zeilenorientierten Ablage wie in Abbildung 2.3 aussehen: Die Werte werden Zeile für Zeile untereinandergeschrieben.

Abbildung 2.3: HANA-Tabelle – zeilenorientierte Ablage (Row Store)

Im Gegensatz dazu speichert die spaltenorientierte Ablage jede Spalte als eigene physische Tabelle. In unserem Beispiel wären das die Tabellen Stadt, Bundesland und Einwohner.

Anschließend werden diese einzelnen Tabellen sowohl komprimiert als auch sortiert. Bei der Komprimierung werden Duplikate entfernt. In unserem Beispiel können bei den Bundesländern Blöcke eingespart werden, da NRW mehrfach vorkommt. Dies reduziert den für die Daten benötigten Speicher.

Durch die Sortierung der einzelnen Werte kann später schneller auf die Daten zugegriffen werden. Beide Schritte sehen Sie zusammengefasst in Abbildung 2.4.

Abbildung 2.4: HANA-Tabelle – spaltenorientierte Ablage (Column Store)

Tabelle 2.1: Vergleich zeilen- und spaltenorientierte Speicherung

Basierend auf dem gegebenen Beispiel, möchte ich die Vor- und Nachteile beider Speichervarianten exemplarisch zusammenfassen (siehe auch Tabelle 2.1).

Um zu entscheiden, welche Variante besser für ein gegebenes Szenario passt, sind zwei Kriterien wichtig:

 die Struktur der erwarteten Daten sowie

 deren spätere Verwendung.

Datenstruktur

In dem gegebenen Beispiel mit nur sehr wenigen Daten ergibt die Auswahl der Speichermethode keinen großen Unterschied. Stellen Sie sich dagegen deutlich größere Tabellen mit Millionen von Zeilen und sehr vielen Spalten vor. Die Wahrscheinlichkeit, dass in einigen dieser Spalten duplizierte Werte enthalten sind, ist, abhängig von der Datenart, recht hoch. Durch die Komprimierung kann viel Platz eingespart werden. Wenn die Tabelle allerdings nur sehr wenige Duplikate enthält, wäre der Vorteil bei der Speichernutzung der spaltenorientierten Variante äußerst gering.

Datenverwendung

Wenn die Tabelle für analytische Auswertungen genutzt werden soll, bietet sich eine spaltenorientierte Ablage an, da die Werte der einzelnen Spalten direkt miteinander in Verbindung gebracht werden können. Dadurch sind z.B. Aggregationen über viele Zeilen hinweg bei der spaltenorientierten Ablage deutlich effizienter umsetzbar als bei der zeilenbasierten Ablage.

Wird die Tabelle hingegen stark transaktional beschrieben, wie etwa bei Bestellungen, die über einen Online-Shop aufgenommen werden, kann eine zeilenorientierte Speicherung von Vorteil sein, da eine schnellere Ablage der Daten erfolgt.

Bei der Entwicklung des Datenmodells für Ihre Anwendung ist es auf jeden Fall wichtig, sich frühzeitig Gedanken zu machen, welche Daten abgelegt und wie die Tabellen genutzt werden sollen. Sie müssen sich pro Tabelle für eine der beiden Speichermethoden entscheiden.

Konfiguration der Speicherart für HANA-Tabellen

Wie Sie die Speicherarten für Tabellen innerhalb der HANA-Plattform festlegen, ist in den Beispielen des Kapitels 5 beschrieben.

2.1.3 HANA Processing Services

Durch die Einbindung verschiedener Processing Services in die HANA-Plattform hat die SAP den Funktionsumfang der Datenbankplattform stark erweitert. Mithilfe dieser Services können Sie unterschiedliche analytische Aufgaben direkt in einem Datenbanksystem ausführen. Neben den von der SAP angebotenen Produkten, die auf der HANA-Technologie basieren, können auch Ihre Entwicklungsprojekte von dem zusätzlichen Funktionsumfang der Processing Services profitieren.

Eine detaillierte Beschreibung der einzelnen Processing Services wäre für dieses Buch zu umfänglich. Aus diesem Grund möchte ich Ihnen an dieser Stelle nur einen Überblick über die aktuell integrierten Funktionen geben. Die nachfolgende Auflistung ist eine Momentaufnahme des aktuellen Stands der SAP-HANA-Plattform (Version 2.0 SPS 05) und kann sich im Laufe der Zeit gemäß der SAP-Produktstrategie verändern.

Spatial

Durch die Verwendung der Spatial-Funktionen können Anwendungen geografische Daten direkt verarbeiten. Auf diesem Weg werden Ihre Daten in einen räumlichen Zusammenhang gebracht, z.B. indem der Abstand zwischen zwei Punkten oder die Größe von Flächen berechnet wird.

Die HANA-Plattform unterstützt bei der Verarbeitung geografischer Daten offene Standards, sodass sich auch Daten von Fremdsystemen unkompliziert integrieren lassen.

Graph

Der Graph-Service ermöglicht die native Graphenverarbeitung innerhalb der HANA-Plattform. Durch ihn können Beziehungen zwischen Menschen, Orten und Dingen hergestellt werden. Das Ziel bei der Graphenverarbeitung ist die Analyse einer komplexen Realität hochgradig vernetzter Daten.

Die HANA-Plattform bietet Modellierungs- und Visualisierungstools, um Graphen zu erstellen und in diesen zu navigieren, Muster aufzudecken, kürzeste Wege zu berechnen und Beziehungen zu verstehen.

Series Data

Die Funktionalität Series Data von HANA kann Reihendaten entgegennehmen und direkt verarbeiten. Diese Daten werden z.B. über die Streaming Engine von Geräten oder Sensoren des IoT (Internet der Dinge) erzeugt und an SAP HANA gesendet.

SAP HANA verarbeitet Reihendaten, um Trends über einen bestimmten Zeitraum zu ermitteln. Sie können beispielsweise Preisschwankungen, saisonale Verschiebungen, Maschineneffizienz, Energieverbrauch oder Netzwerkflüsse überwachen, um Muster zu entdecken.

JSON Document Store

Der JSON Document Store ist in der HANA-Plattform ab Version 2.0 SP1 verfügbar und ermöglicht die Ablage sowie die Verarbeitung von verschachtelten JSON-Objekten.

Ein großer Vorteil der Datenspeicherung in JSON-Objekten gegenüber derjenigen in relationalen Tabellen ist die Flexibilität der Struktur. Das JSON-Dokument lässt sich flexibel und dynamisch auf die sich ändernden Bedürfnisse anpassen und ablegen. Bei einer relationalen Speicherung von Daten müssten für strukturelle Anpassungen erst die Datenbankstrukturen modifiziert werden.

Auf die JSON-Dokumente können Sie direkt mit SQL-Mitteln zugreifen. Sie werden also abgefragt, als wären sie in strukturierter Form (relationale Datenbank) abgelegt worden.

Search

Der Search-Service stellt besondere Funktionen für eine übergreifende Suche zur Verfügung. Er unterstützt für die Volltextsuche unterschiedliche Optionen wie »EXACT«, »LINGUISTIC« und »FUZZY«. Um die Suchfunktionen nutzbar zu machen, werden die Datenbankinhalte mittels Suchindizes speziell für Suchanfragen vorbereitet.

Da die Suchfunktionalität besonders häufig bei der Entwicklung eigener Software verwendet wird, habe ich bei den Beispielen des Kapitels 5 den Search-Service exemplarisch mit eingebunden.

Text Analytics

Die Textanalyse der HANA-Datenbank umfasst Funktionen für die Verarbeitung von natürlicher Sprache und die Extraktion von Entitäten mittels Funktionen wie Segmentierung, Stemming und Tagging.

Dadurch werden unstrukturierte Daten für eine Analyse in strukturierte Daten umgewandelt und in der Datenbank abgelegt. Des Weiteren werden zusätzliche Algorithmen für Text Mining und Stimmungsanalysen (Sentiments) zur Verfügung gestellt, um relevante Schlüsselwörter aus Dokumenten abzuleiten.

Streaming Analytics

Eine weitere Ergänzung zur Datenbank ist die Smart Data Streaming Engine. Mit ihr lassen sich Ereignisströme aus vielen Quellen in Echtzeit erfassen und verarbeiten. SAP HANA unterstützt eine SQL-ähnliche Verarbeitungssprache, um Streams mit kontextbezogenen Daten zu kombinieren und das Ergebnis direkt (on the fly) zu analysieren.

Für eine bessere Skalierbarkeit wird die "Streaming Lite"-Komponente bereitgestellt, die Sie vorab auf der Streaming-Datenquelle einsetzen können. Diese analysiert und filtert die Streamdaten, bevor sie SAP HANA erreichen.

Predictive

Mit der Predictive Analysis Library (PAL) wird ein großes Set (aktuell 93) direkt ausführbarer Algorithmen ausgeliefert. Diese gliedern sich in die Bereiche »Clustering«, »Classification«, »Regression«, »Association«, »Time Series«, »Preprocessing«, »Statistics«, »Social Network Analysis«, »Recommender System« und »Sonstige«. Die Auswahl der einzelnen Algorithmen basiert auf den folgenden Kriterien der SAP:

 Die Algorithmen werden für SAP-Anwendungen benötigt.

 Die Algorithmen werden, basierend auf Markterhebungen, am häufigsten verwendet.

 Die Algorithmen sind im Allgemeinen auch in anderen Datenbankprodukten verfügbar.

Business Functions

Die Business Function Library (BFL) liefert neben der Predictive Analysis Library ein ergänzendes Set an Algorithmen (aktuell 55), mit denen vorgefertigte parametergesteuerte Funktionen im Finanzbereich zur Verfügung gestellt werden.

Machine Learning

Machine Learning (ML) Services beinhalten ein umfassendes Set an Tools und Funktionen, mit denen sich intelligente Anwendungen erstellen lassen.

Das ML-Toolset ist in die folgenden Bereiche gegliedert:

 Eingebettete ML-Bibliotheken wie die bereits beschriebenen PAL und BFL. Ergänzend wird die Automated Predictive Library (APL) zur Verfügung gestellt, mit der die zuvor beschriebenen Vorhersagealgorithmen auch automatisiert verwendet werden können.

 Spezielle API-Schnittstellen für externe R-Programme (R Machine Learning API), Python-Programme (Python Client API for ML) oder SQL-Clients (SQL Client API)

 Integration externer ML-Server, wie »TensorFlow« oder »Rserve/R Runtime«, über die External Machine Learning Library (EML)

Welche der zuvor beschriebenen Processing Services Sie in Ihre Anwendungsentwicklung einbinden, entscheiden Sie je nach Anwendungsfall.

Informationen zu den HANA Processing Services

Weitere Details zu den einzelnen Diensten und dem jeweils darin enthaltenen Funktionsumfang erhalten Sie über die folgenden Internetseiten:

 Allgemeine Informationen: https://www.sap.com/products/hana.html

 Detaillierte Informationen: https://help.sap.com/viewer/product/SAP_HANA_PLATFORM

Die Technologien, die diesen Services zugrunde liegen, sind im Übrigen keine SAP-Erfindungen, sondern werden auch von anderen Herstellern in ähnlicher Form umgesetzt. Mit den unterschiedlichen Processing Services als Suchbegriff werden Sie diverse Internetquellen mit weiteren Details und Hintergründen finden.

Ein wichtiger Aspekt ist, dass die einzelnen Funktionen der hier dargestellten Services vollständig in die gemeinsame Plattform integriert sind. Demzufolge haben Sie die Möglichkeit, in einer Anwendung auch komplexe und Engine-übergreifende Anforderungen umzusetzen. Sie müssen für die Realisierung nicht auf unterschiedliche Systeme zurückgreifen, zwischen denen die Daten hin- und hertransferiert werden. Beispielsweise können Sie Zusammenhänge geografischer Daten (Spatial) mit Graph-Algorithmen auswerten und diese Erkenntnisse mit relevanten Geschäftsdaten kombinieren oder durch Machine-Learning-Algorithmen weiter analysieren. Die SAP spricht bei dieser Integration diverser Dienste von »Multi-Model Processing« und »Advanced Analytics Processing«, also der Verarbeitung verschiedener Modelle auf einer Plattform.

Ich werde in diesem Buch nicht weiter auf die Datenbankarchitektur oder die Detailfunktionen der Processing Services eingehen. In den weiteren Kapiteln werde ich die Softwareentwicklung auf der integrierten Plattform in den Mittelpunkt stellen. Wichtig ist, dass Sie für Ihre Eigenentwicklungen den gesamten Funktionsumfang der HANA-Plattform (entsprechend Ihrer Lizensierung) nutzen können.

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.

XSC und XS Engine

Zum Zeitpunkt der Veröffentlichung der XSC wurde noch nicht zwischen Classic und Advanced unterschieden. Die Extended Application Services wurden anfangs als »XS Engine« bezeichnet. Erst mit der Einführung der »Advanced«-Variante (XSA) wurde die XS Engine in XSC umbenannt.

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.

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.