Höher, schneller, weiter
Sämtliche Open SQL nutzende Abap-Anwendungen und Add-ons sind datenbankkompatibel, laufen also auf verschiedenen DB-Systemen (MS-SQL, MaxDB, Oracle) und können somit auch auf Hana betrieben werden.
„Applikationsserver und DB-Server kommunizieren über eine Datenbankverbindung. Alle für den angestoßenen Befehl erforderlichen Daten werden in den Applikationsserver geladen, wo dann sämtliche Rechenoperationen und Codings durchgeführt werden. Das funktioniert bei herkömmlichen Datenbanken genauso wie mit Hana“
doch der Nachteil dieser Vorgehensweise liegt für Florian Lenz, Head of Departement Forecast bei G.I.B, auf der Hand:
Bei großen Datenvolumina entstehen lange Wartezeiten durch den Datentransfer zwischen Datenbank und Applikationsserver. Aber es sollte doch durch Hana alles schneller werden?
„Es kann ohne Optimierungen Performance-Gewinne geben, muss aber nicht, schließlich werden weiterhin alle wesentlichen Rechenoperationen im Applikationsserver vorgenommen und der ist derselbe geblieben“
erklärt Lenz.
Wenn es um Echtzeitanalysen und mehr Funktionalität gehe, dann müssten möglichst viele Codings in Hana selbst durchgeführt werden.
Doch alles umprogrammieren?
„Je besser das Programm die spaltenorientierte Datenbanklogik nutzt und je mehr Statements aus Hana genutzt werden und je mehr Operationen auf Hana durchgeführt werden, desto schneller das Programm“
meint Lenz und ergänzt:
„Das geht zulasten der Datenbank-Kompatibilität.“
Er selbst habe für eines der Programme aus der G.I.B-Dispo-Cockpit-Familie den Mittelweg gewählt, indem er sämtliche Datentransferpunkte mit einer Weiche versehen hat.
„Das Programm erkennt nun, ob eine Hana oder eine konventionelle Datenbank zugrunde liegt. Bei einer Hana weicht das Programm vom ,normalen‘ Prozedere ab und verlagert das Coding in den Hana-Server.“
Dieses als Code-push-down bezeichnete Vorgehen birgt enormes Potenzial. Stefan Renk, Leiter SCM-Prozesse beim Lichthersteller Trilux, berichtete bereits nach einer Woche Live-Einsatz des Add-ons G.I.B DCF on Hana von Performanceverbesserungen um 90 Prozent in einzelnen Aktionen. Dabei arbeitet Trilux zurzeit noch mit einer By-side-Lösung, für Lenz ist das nur eine Zwischenlösung:
„Der gewohnte ERP-Server mit der bestehenden Datenbank bleibt weiter in Betrieb. Nur ein Teil der Daten migriert in die Hana und wird über den LT-Replication Server aktuell gehalten.“
Gerade im mobilen Anwendungsbereich eröffnet Hana neue Dimensionen. Dabei ist zu beachten, dass besonders hier die Ergebnismenge möglichst vollständig in Hana berechnet wird, denn der mobile Nutzer erwartet Ergebnisse auf Knopfdruck, auch bei Massendaten-Analysen. Ein ansprechendes User-Interface gehört auch dazu.
„Es ist eine Herausforderung, eine komplexe Anwendung so zu zerpflücken, dass sinnvolle Apps entstehen.
Die Bestimmung homogener Benutzergruppen, die Reduktion von Sachverhalten und Prozessen auf das Wesentliche und der Mut, sich von Funktionen zu trennen, sind grundlegende Vorgänge bei der Konzeption. Diese Apps sollen selbsterklärend sein und in drei bis vier Schritten zum Ziel führen. Es ist kompliziert, Einfachheit bereitzustellen“
scherzt Lenz.
Run simple
Simplifizierung ist auch das Stichwort für S/4 Hana, das neue Zeitalter der Business Suite. Anders als bisher setzt SAP hier nicht mehr auf Datenbank-Kompatibilität:
„Mit S/4 sind Anwendung und Datenbank perfekt gematcht. Nahezu sämtliche Codings sollten dann in Hana ausgeführt werden, so wird der Datentransfer zum Endgerät minimiert“
erklärt Lenz und ergänzt, dass das Zusammenspiel von Fiori, Simplifizierung und Hana neue Leistungsdimensionen eröffnet. Dabei sei zu beachten, dass auf Entwicklerseite nicht nur Abap-Kenntnisse, sondern weitere Skills in Javascript, SQL und SQL Script benötigt werden.
„Bei allen Vorteilen muss beachtet werden: Sämtliche S/4-Hana-Anwendungen lassen sich ausschließlich mit einer Hana-DB betreiben“
bemerkt Lenz.
