Buch lesen: «Cloud-Entwicklung in SAP HANA»

1 Einleitung

Lassen Sie uns mit einem Blick zurück in die Vergangenheit beginnen. Ich möchte Ihnen darstellen, wie die SAP in den letzten zehn Jahren den Weg zu einer modernen Datenbank- und Entwicklungsplattform verfolgt hat und warum es für Sie und Ihr Unternehmen von Vorteil sein kann, das aktuelle SAP-Datenbanksystem für Ihre Softwareprojekte zu nutzen.

Meine Rückschau startet mit dem Veröffentlichungszeitpunkt der SAP-eigenen In-Memory-Datenbank HANA. Basierend darauf stelle ich Ihnen den leichtgewichtigen Applikationsserver mit dem Namen »Extended Application Services Classic« (XSC bzw. XS, wie er früher genannt wurde) vor, um mich abschließend dem Hauptfokus dieses Buches zu widmen: der auf modernen Cloud-Technologien basierenden Plattform »Extended Application Services Advanced« (XSA).

1.1 HANA im Rückblick

Als die SAP im Jahr 2011 die erste Version der HANA-Datenbank veröffentlichte (Kundenfreigabe am 05.09.2011), wurde dem Produkt viel Aufmerksamkeit gewidmet. Die SAP versprach erhebliche Performancegewinne für die auf HANA aufsetzenden SAP-Anwendungen.

Bei öffentlichen Veranstaltungen, wie beispielsweise der SAP TechEd, wurde von deutlich verbesserten Abläufen in Kundenumgebungen berichtet – Abläufe, die mit der HANA-Technologie 100.000-mal schneller seien als ohne. Der Kreis der Kunden, die solche Performancegewinne erzielten, wurde von der SAP medienwirksam inszeniert. Man sprach von dem »100k-Club«.

Diese sehr plakativen und eher marketinglastigen Aussagen über die Potenziale der HANA-Technologie konnten allerdings in verschiedenen Kundenprojekten tatsächlich realisiert werden.

Um die Vorteile besser zu verstehen und vor allem auch für eigene Softwareprojekte nutzen zu können, ist es wichtig, Details der HANA-Technologie zu betrachten. Darauf werde ich im Abschnitt 2.1 zu sprechen kommen. Dabei werde ich auf weitere Besonderheiten der HANA-Architektur eingehen und Ihnen einen Überblick über die HANA Processing Services (z.B. Search, Spatial, Predictive & Planning, Machine Learning) geben, mit denen spezifische Logiken direkt innerhalb der Datenbank umgesetzt werden. Diese Processing Services erweitern das Datenbanksystem um zusätzliche Funktionen und ermöglichen spezielle, integrierte Anwendungsszenarien.

Abbildung 1.1 stellt das Produkt SAP HANA unter Berücksichtigung der Processing Services und Entwicklungsaspekte dar.

Abbildung 1.1: SAP HANA – Business Data Platform

Im Zentrum der Grafik sehen Sie die einzelnen Funktionen der HANA-Datenbank, auf der linken Seite die Möglichkeit, externe Daten zu integrieren, und auf der rechten Seite das Thema Anwendungsentwicklung, zu dem auch die XSA-Umgebung gehört, um die es in diesem Buch primär geht.

Ein weiterer wichtiger Aspekt bei der Markteinführung der HANA-Datenbank war die Aussage der SAP, dass HANA die alleinige Datenbanktechnologie für moderne SAP-Systeme (S/4HANA, BW/4HANA etc.) sei. Innovationen werde man ausschließlich auf Basis der HANA-Technologie ausrollen. Dies bedeutet für alle SAP-Kunden, dass sie mittel- bis langfristig mit dem Thema HANA in Berührung kommen werden.

Ergänzend ermöglicht die SAP ihren Kunden die Nutzung der HANA-Technologie für Eigenentwicklungen außerhalb des ABAP-Stack oder anderer SAP-Produkte. Zu diesem Zweck stellt sie ein eigenes Lizensierungsmodell zur Verfügung.

HANA-Lizenzen

SAP unterscheidet bei der HANA-Datenbank zwischen folgenden Lizenzmodellen:

 Runtime-Lizenz: Sie wird benötigt, um HANA für SAP-Produkte zu verwenden (z.B. bei der Business Suite).

 Platform-Lizenz: Sie ist für Eigenentwicklungen auf HANA erforderlich. Bei diesem Modell wird zusätzlich der jeweils zur Verfügung stehende Funktionsumfang lizensiert.

1.2 Extended Application Services

Damit auch vollständige Anwendungen (also inklusive Anwendungslogik und Oberflächen) auf der Datenbankplattform entwickelt werden können, hat die SAP neben der Datenbank die sogenannten Extended Application Services (XS) eingeführt. Die Idee dahinter ist eine Plattform zur Entwicklung kundeneigener Anwendungen, die die Funktionen der HANA-Datenbank vollumfänglich nutzen können. Auch die SAP selbst erweitert über die XS den Funktionsumfang der SAP-HANA-Plattform insgesamt.

Zunächst wurde der mittlerweile als Extended Application Services Classic (XSC) benannte Ansatz angeboten. Die Technologie erwies sich allerdings als sehr proprietär und zeigte architektonische Schwachstellen. Beispielsweise konnte die XSC-Umgebung nicht unabhängig von der HANA-Instanz skaliert werden. Des Weiteren war die Laufzeitumgebung an einen HANA-Prozess gekoppelt, was insbesondere aus Stabilitätsgründen problematisch ist.

Basierend auf den Erfahrungen mit XSC hat die SAP eine komplette Neuausrichtung des Themas »Extended Application Services« in die Wege geleitet. Mit SAP HANA 1.0 SP11 wurden den Kunden erstmalig die Extended Application Services Advanced (XSA) zur Verfügung gestellt. An dieser Stelle möchte ich darauf hinweisen, dass die Nähe der XSA zur XSC fast ausschließlich über den Namen (Classic und Advanced) gegeben ist. Bei der XSA handelt es sich um einen cloudbasierten Ansatz, der auf offenen Standards aufbaut. Weitere Details und vor allem die wichtigsten Unterschiede zwischen den Umgebungen XSC und XSA schildere ich im Abschnitt 2.2. Auf die XSA-Architektur gehe ich in Abschnitt 2.3.4 genauer ein.

Nachdem wir bisher fast ausschließlich die Vergangenheit betrachtet haben, möchte ich Ihnen einen weiteren wichtigen Aspekt der aktuellen HANA-Datenbank und im Besonderen der XSA-Umgebung aufzeigen, an dem sich zeigt, dass bei der XSA entscheidende Aspekte anders als in der Vergangenheit gehandhabt werden.

1.3 Eigenentwicklungen der SAP

Wenn man das Thema »Softwareentwicklung im SAP-Umfeld« betrachtet, handelt es sich in den meisten Fällen um proprietäre Technologien. In einem SAP-System wird mit der Programmiersprache ABAP entwickelt. Diese wurde speziell von der SAP entworfen, um SAP-Anwendungen wie das ERP bzw. die Business Suite zu realisieren. Bei der Fragestellung, wie Software durch die verschiedenen Systemumgebungen wie Entwicklung, Test und Produktion transportiert werden kann, setzt die SAP auf das Transport Management System (TMS), auf Erweiterungen wie das Enhanced Change and Transport System (CTS+) und auf das SAP Change Request Management (ChaRM) – alle ebenfalls Eigenentwicklungen der SAP.

Neben der Programmiersprache und den zu verwendenden Werkzeugen unterscheidet sich bei diesen Lösungen das Vorgehen während des Entwicklungsprozesses. So wird in ABAP beispielsweise der gesamte Quellcode im Laufzeitsystem (also dem Entwicklungssystem) vorgehalten. Möchte der Entwickler seinen Quellcode ausführen, muss er ihn zunächst auf diesem System aktivieren. Eine zentrale Quellcode-Verwaltung, in der mehrere Entwickler an unterschiedlichen Versionen und Strängen der Software arbeiten, ist nicht vorgesehen.

Die Entwicklung eigener Tools unter Verwendung proprietärer Technologien hat in vielen Fällen ihre Daseinsberechtigung, denn für spezielle Anforderungen werden besondere Werkzeuge benötigt. Das Beispiel von ABAP und dem ABAP-Stack zeigt sogar, dass der Erfolg eines Produkts durch Einsatz einer solchen Technologie klar begünstigt werden kann. Das SAP-ERP-System wäre vermutlich nicht so erfolgreich geworden, hätte man es nicht mit ABAP, sondern mit einer anderen Programmiersprache entwickelt. Gerade die konsequente Ausrichtung der Sprache auf die Anforderungen eines ERP-Systems waren und sind der Schlüssel zum Gelingen. Auch die für den Entwicklungsprozess dargestellten Werkzeuge weisen erhebliche Vorteile auf und zeigen, dass eine Eigenentwicklung der SAP die SAP-Systeme bestmöglich unterstützt.

Auf der anderen Seite kann der Einsatz eigener Technologien insofern problematisch sein, als der Kreis derer, die sich damit auskennen, eher begrenzt ist. Zudem kann bei Fragen oder Problemen nicht auf große, bereits vorhandene Communitys zurückgegriffen werden. ABAP ist keine Programmiersprache, die etwa in den Universitäten oder anderen Ausbildungsstätten zum Standard für angehende IT-Experten gehört.

Ich möchte an dieser Stelle ein Beispiel für eine aus meiner Sicht weniger erfolgreiche Umsetzung einer SAP-Eigenentwicklung anführen: Java von SAP.

SAP hatte geplant, Java-Entwickler, die noch keine Berührungspunkte mit dem SAP-Universum hatten, für SAP-Entwicklungen zu gewinnen. Verständlicherweise, denn der Markt ist riesig, da Java eine der beliebtesten Programmiersprachen mit einer sehr ausgeprägten Community ist.

Um dieses Ziel zu erreichen, wurde der SAP Web Application Server (SAP WebAS, später NetWeaver AS) in zwei Varianten – als ABAP-Stack und als Java-Stack – bereitgestellt. Neue Produkte wurden entweder für den ABAP-Stack (z.B. ERP) oder für den Java-Stack (z.B. Portal) entwickelt. Einige basierten sogar auf beiden Stacks, wie der Solution Manager. Der eigene Applikationsserver im Java-Umfeld (SAP NetWeaver AS Java) wird nicht mehr weiterentwickelt und aller Wahrscheinlichkeit nach mit der aktuellen Version 7.5 auslaufen. Ebenso erging es dem Thema »Software-Logistik im Java-Umfeld« mit der Eigenentwicklung SAP NetWeaver Development Infrastructure (NWDI). Auch diese wurde nur mit mäßigem Erfolg vom Markt akzeptiert.

Java-Entwickler konnten jedenfalls nur ganz begrenzt für die SAP-Plattformen gewonnen werden. Ein Grund dafür ist meines Erachtens, dass sich viele der Java-Entwickler nicht auf die SAP-Besonderheiten einlassen wollten. Allzu häufig unterschied sich die SAP-eigene Java-Entwicklung von der allgemein bekannten, und zwar sowohl in der Programmierung als auch in dem Werkzeugkasten, der für die Entwicklung verwendet werden musste (z.B. die erwähnte SAP NWDI).

Anhand der genannten Beispiele stellt sich die Frage, welche Erkenntnisse die SAP aus den Erfahrungen mit der eigenen Java-Umgebung gezogen hat. Genau an dieser Stelle komme ich zum Thema XSA zurück, denn in der XSA-Umgebung lässt sich Software auch mittels Java entwickeln. Im Unterschied zum Ansatz des NetWeaver AS Java kann in der XSA Standard-Java-Code entwickelt werden. Es gibt fast keine Einschränkungen, wie die Sprache zu verwenden ist. Als Entwickler können Sie damit genauso entwickeln, wie Sie es außerhalb der SAP-Welt tun würden. Gerade für Programmierer, die bis dato noch keine Berührungspunkte mit SAP-Systemen hatten, ist dies ein erheblicher Vorteil.

1.4 Cloud als Strategie

Neben der Möglichkeit, eine SAP-fremde Programmiersprache wie beispielsweise Java zu verwenden, ist noch ein weiterer Aspekt wichtig, der die XSA-Umgebung als moderne Entwicklungsplattform ausweist.

Mittlerweile sind Begriffe wie »cloud native« und »cloud first« auf dem Vormarsch. Gerade bei Eigenentwicklungen ist es inzwischen maßgeblich, ob Software auch in einer Cloud-Umgebung lauffähig ist oder nicht. Aktuell drängen sowohl Softwarehersteller als auch Kunden in die Cloud und erwarten die »Cloudfähigkeit« natürlich ebenso von einer modernen Entwicklungsplattform.

Genau bei diesem Thema kann die XSA überzeugen. Die Art und Weise, wie mit der XSA-Umgebung Software entwickelt wird, basiert auf Cloud-Konzepten. Eine Anwendung, die in der XSA läuft, kann demnach auch in einer Cloud-Umgebung bereitgestellt werden.

Weitere Details zum Themenschwerpunkt »Cloud« gebe ich in Kapitel 3.