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