Strategien


SAPs In-Memory-Datenbank

SAP HANA als Applikationsplattform

24.01.2014
Von Uwe Sester

Häufig lassen sich in Kundeninstallationen verschiedene Evolutionsstufen erkennen. Zunächst wird HANA im Side-by-Side-Reporting-Szenario eingesetzt, das dann durch ein BW auf HANA ergänzt wird, gefolgt von der Business Suite. Vollständig native Szenarien bilden die letzte Stufe in dieser Kette und sind meist die logische Konsequenz einer In-Memory-Strategie. Wenn es jedoch um eine vollständige Eigenentwicklung geht, bietet sich an, direkt mit einem nativen Szenario zu beginnen und HANA als Plattform dafür zu verwenden.

Schichtenmodell in HANA

Eine klassische SAP-Anwendung wird in aller Regel im Drei-Schichten-Modell mit einer Datenbank-, einer Applikations- und einer Präsentationsschicht umgesetzt. Auch bei nativen Applikationen mit HANA findet dieses Modell Anwendung. Die beiden Schichten Applikation und Datenbank fallen hier allerdings zusammen und werden gemeinsam in HANA realisiert. Daraus resultiert eine Verschlankung der Applikationsarchitektur, der Applikationscode wird direkt dort ausgeführt, wo auch die Daten liegen. Anwender benötigen keinen separaten Applikations-Server mehr.

Für die Anwendungsentwickler stellt sich nun die Frage, wie diese unterschiedlichen Schichten in einer nativen Anwendung mit HANA umzusetzen sind. Die Datenbankschicht und ein Teil der Applikationsschicht werden mit SQLScript implementiert, einer HANA-spezifischen Erweiterung des SQL-Standards. Dabei kommen üblicherweise wiederverwendbare Prozeduren zum Einsatz. Die Präsentationsschicht wird in aller Regel durch eine Web-Anwendung realisiert. Hier empfiehlt sich der neueste Standard HTML5.

Die SAP-eigene Bibliothek zum Erstellen solcher Anwendungen (SAP UI5) liefert der Hersteller direkt mit HANA aus. Um von der Präsentationsschicht (realisiert in HTML) auf die Applikations- und Datenbankschicht (realisiert in SQLScript) zugreifen zu können, kommt eine weitere Komponente von HANA zum Einsatz: die "Extended Application Services" (XS Engine). Diese dienen als leichtgewichtiger Applikations-Server und gleichzeitig als Web-Server für die Präsentationsschicht. Über sie lassen sich SQL-Prozeduren per HTTP-Services der Präsentationsschicht zugänglich machen.

Szenarien ohne Zugriff über Applikations-Server: HANA-Architekturen kommen auch ohne Applikations-Server aus. BI-Anwendungen beziehungsweise native Eigenentwicklungen können auch direkt auf HANA laufen.
Szenarien ohne Zugriff über Applikations-Server: HANA-Architekturen kommen auch ohne Applikations-Server aus. BI-Anwendungen beziehungsweise native Eigenentwicklungen können auch direkt auf HANA laufen.
Foto: Camelot ITLab

Sie sind direkter Bestandteil von HANA und erlauben damit einen performanten Zugriff auf die Prozeduren. Als Entwicklungssprache kommt Javascript zum Einsatz, das in der XS Engine ausgeführt wird. Der Javascript-Standard wird durch HANA-spezifische Bibliotheken erweitert und bietet alle Funktionen, die gebraucht werden, um Geschäftsapplikationen zu erstellen.

Ebenso haben Entwickler Zugriff auf zusätzliche HANA-Bibliotheken wie die Textanalyse oder die "Business Function Library", in der wiederverwendbare betriebswirtschaftliche Funktionen abgelegt sind: etwa die Berechnung von Forderungslaufzeiten oder Kundenklassifizierungen.

Zur Startseite