SAPs In-Memory-Datenbank

SAP HANA als Applikationsplattform

Datum:20.01.2014
Autor(en):Uwe Sester

Mit HANA hat SAP¹ eine auf In-Memory-Technik basierende Plattform entwickelt, die das Potenzial hat, die Paradigmen und Vorgehensweisen bei der Entwicklung von Geschäftsapplikationen maßgeblich zu verändern. Zunächst müssen sich Entwickler jedoch für eine Anwendungsarchitektur entscheiden. Dabei gibt es die Wahl zwischen zwei Gruppen von Szenarien, die sich in der Art des Zugriffs auf SAP HANA unterscheiden. In der ersten Gruppe wird ein ABAP-Applikations-Server verwendet, der für die Zugriffe auf HANA zuständig ist. In der zweiten Gruppe hingegen erfolgt der Zugriff direkt auf HANA².

ABAP-Applikations-Server

In der ersten Gruppe lassen sich zwei Szenarien unterscheiden:

• das "Accelerator"-Szenario und

• HANA als primäre Persistenz.

Beim Accelerator-Szenario wird HANA als zusätzliche Datenbank neben der primären Datenbank eingesetzt. Ausgewählte Zugriffe aus bestehenden Prozessen erfolgen dabei nicht auf der primären Datenbank, sondern werden über eine zweite Verbindung auf HANA umgeleitet und somit beschleunigt. Dieses Szenario ist mit einem vergleichsweise geringen Aufwand verbunden. Bestehende Prozesse lassen sich ohne Unterbrechung weiter nutzen. Ein Beispiel für dieses Szenario ist der von SAP entwickelte CO-PA Accelerator, der die Lesezugriffe in der Profitabilitätsanalyse deutlich beschleunigt.

Szenarien mit Zugriff über einen Applikations-Server: Applkations-Server können entweder nur mit HANA als primärer Persistenz arbeiten oder über eine zusätzliche Verbindung auf HANA als zusätzliche Datenbank zugreifen.
Foto: Camelot ITLab

Ein weiteres Szenario aus dieser Gruppe ist das der primären Persistenz. Dazu wird die Datenbank, die unter dem ApplikationsServer liegt, durch HANA ausgetauscht. Alle Daten des Applikations-Servers sind damit automatisch in HANA vorhanden. Der erste Anwendungsfall aus dieser Gruppe war das Business Warehouse ("BW auf HANA"), gefolgt von der Business Suite.

Im Vergleich zum Accelerator-Szenario entstehen allerdings zusätzliche Aufwände, da hier zunächst die Datenbank auf die neue Plattform migriert werden muss. Dafür entfallen jedoch die Aufwände, um die Daten in der primären Datenbank und in HANA³ parallel zu halten, was im Ergebnis zu einer Vereinfachung der Systemlandschaft beiträgt. Durch die Migration lassen sich auch die erweiterten Funktionen von HANA einfach nutzen.

Direkter Zugriff auf HANA

In der zweiten Gruppe erfolgen die Zugriffe direkt auf HANA und nicht über einen Applikations-Server. Auch diese Gruppe bietet zwei verschiedene Szenarien:

• das "Side-by-Side"-Reporting und

• native Szenarien.

Im ersten Szenario werden Daten aus den jeweiligen SAP- und Nicht-SAP-Systemen nach HANA übertragen und dort im nächsten Schritt beispielsweise mit den Business Intelligence-Tools von Business Objects ausgewertet. Im zweiten Szenario - dem neuesten aus der HANA-Welt - befindet sich sämtliche Applikations- und Datenlogik vollständig in HANA. Die Benutzeroberfläche für solche Applikationen wird üblicherweise mit "SAP UI5" als Web-Anwendung realisiert und ebenfalls in HANA gehostet.

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

Foto: Wolfram Scheible, SAP AG

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.

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

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.

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.

Wie bei der klassischen Entwicklung im SAP-Umfeld ist auch für native Szenarien eine detaillierte Spezifizierung der zu erstellenden Applikation erforderlich. Ein besonderer Fokus sollte dabei auf die Definition der HTTP-Services gelegt werden. Es empfiehlt sich, in abgeschlossenen, zustandslosen Einheiten wie "Kunde anlegen" oder "Bestellung auslösen" zu denken. Alle Daten, die der Service zur erfolgreichen Ausführung benötigt, müssen in der Schnittstelle als Parameter vorgesehen werden. Für eine reibungslose Entwicklung ist es wichtig, diese Definition einzuhalten, da keine integrierte Prüfung über alle Komponenten stattfinden kann, was die Ursachensuche im Fehlerfall aufwendig gestaltet.

Spezifikation der Komponenten

In SAP HANA sind viele unterschiedliche Komponenten vorhanden. Daher sollte man bereits in der Entwurfsphase spezifizieren, welche Komponenten relevant sind und in welchem Bereich der Anwendung sie zum Einsatz kommen. Zudem ist es sinnvoll, die Verantwortlichkeit der jeweiligen Komponente zu definieren. Beispielsweise sollte in der XS Engine keine Applikationslogik implementiert werden, sondern lediglich die notwendigen Datentransformationen zwischen den unterschiedlichen Schichten. Die eigentliche Logik befindet sich dann in der darunterliegenden Schicht und lässt sich dort optimal parallelisieren, was die Ausführungsgeschwindigkeit steigert.

Applikationsarchitektur mit HANA als Plattform: Auch bei nativen Applikationen mit HANA findet das klassische Drei-Schichten-Modell Anwendung: Datenbank-, Applikations- und Präsentationsschicht.
Foto: Camelot ITLab

Profil für Anwendungsentwickler

Anhand der einzusetzenden Techniken lassen sich Anforderungen an das technische Profil von Anwendungsentwicklern ableiten. Für die Präsentationsschicht werden Entwickler benötigt, die Web-Techniken rund um HTML und Javascript abdecken können. Ein Web-Designer ist wichtig, um eine visuell ansprechende Applikation zu gestalten. Die Javascript-Kenntnisse des Web-Entwicklers eignen sich zudem, um die Zwischenschicht in der XS Engine zu erstellen. Hier muss man sich nur in die HANA-spezifischen Bibliotheken einarbeiten.

Für die eigentliche Logik ist jedoch ein anderes Skillset gefragt. Hier sind tiefe Datenbankkenntnisse rund um SQL und die relationale Modellierung notwendig. Zusätzlich gilt es, die für HANA spezifischen Entwicklungsartefakte zu kennen und sie entsprechend ihrer Intention auch einzusetzen. Eine enge Zusammenarbeit zwischen Frontend- und Backend-Entwicklern hilft, effizient zu wartende Applikationen zu erstellen. Hier hat sich ein agiles Entwicklungsmodell wie Scrum⁴ bewährt.

Darüber hinaus sind zwei weitere Kompetenzbereiche entscheidend: Prozesswissen sowie spezifisches SAP-Know-how, wenn es sich um eine Anwendung handelt, die mit den Daten eines SAP-Moduls arbeitet. Die gleichmäßige Verteilung dieser vier Kompetenzbereiche - Prozesswissen, technisches SAP-Modulwissen, HANA-spezifische⁵ Entwicklungsartefakte und Entwicklungssprachen - entscheidet über eine erfolgreiche Implementierung von nativen HANA-Applikationen. (ba)

Links im Artikel: