Strategien

SAPs In-Memory-Datenbank

SAP HANA als Applikationsplattform

24.01.2014
Von Uwe Sester
In erster Linie soll SAPs In-Memory-Datenbank Analysen und Reporting beschleunigen. Doch mit Hilfe von Zusatzkomponenten lässt sich HANA darüber hinaus auch als Applikationsplattform einsetzen.

Mit HANA hat SAPSAP 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. Alles zu SAP auf CIO.de

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.
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.

Zur Startseite