INFRASTRUKTUR Hana XS · PDF fileINFRASTRUKTUR 98 E-3 JUNI 2014 Plattformen Extended Application Services Hana XS – ein App-Server auf Diät Mit Hana XS lassen sich moderne und

Embed Size (px)

Citation preview

  • INFRASTRUKTUR

    98 E-3 JUNI 2014

    Plattformen

    Extended Application Services

    Hana XS ein App-Server auf DitMit Hana XS lassen sich moderne und leistungsstarke Business-Anwendungen programmieren, die direkt auf der Hana Appliance aufsetzen. Welche Vor- und Nachteile gibt es gegenber klassischen Konzepten, welche Mglichkeiten bietet Hana XS?

    Von Marco Harpenschlger, Andreas Fuchs und Matthias Gehre, Contrimo

    Mit Hana XS (SAP Hana Ex-tended Application Services) hat SAP einen in die Hana-Datenbank (DB) integrierten Anwendungs- und Webserver entwickelt und positioniert diesen als einfache und schlanke Alternative zu den groen Her-stellern von J2EE-Applikationsservern. Damit wird deutlich, dass sich die an-fangs reine Datenbank kontinuierlich zu einer umfassenden Anwendungs-plattform entwickelt. So lassen sich mit Hana XS sowohl kleinere Apps als auch komplexe Business-Anwendungen ent-wickeln direkt auf Hana. Zustzlich ergeben sich gerade in Kombination mit SAPUI5 (dem neuen Frontend-Frame-work der SAP) unzhlige Mglichkeiten, visuell ansprechende, zeitgeme und

    device-unabhngige Anwendungen zu entwickeln. Doch statt wie frher pro-prietre Protokolle und Libraries zu nut-zen, profitiert man nun von offenen und aktuellen Web-Standards wie beispiels-weise HTML5, CSS3, jQuery, Ajax und D3 (Framework zur Datenvisualisierung). Fr uns ein Grund, das Thema Hana XS technisch sowie hinsichtlich zu er-wartender Potenziale zu beleuchten, ins-besondere vor dem Hintergrund neuer Business Cases.

    Hana XS vs. Klassische Architektur

    In traditionellen, dreistufigen Architek-turen ist ein separater Anwendungs-server (z. B. SAP NetWeaver Abap/Java,

    J2EE-Server) fr die Verarbeitung der gesamten Business-Logik zustndig. Dazu werden ber JDBC/ODBC/ADBC (Abap Database Connector) Daten aus der Datenbank bertragen und an-schlieend gepuffert und validiert. Mit steigendem Datenvolumen kann dies allerdings massive Auswirkungen auf die Performance haben.

    Zudem findet im klassischen Modell der Groteil des UI Renderings auf dem Applikationsserver statt, wobei fr den Datenaustausch zwischen Client und App-Server herstellerspezifische Pro-tokolle eingesetzt werden. Im Gegen-satz dazu umfasst das neue Konzept nur noch zwei Layer. Anwendungs-, Business- und datenintensive Berech-

    Klassische Architektur vs. Hana XS.

  • INFRASTRUKTUR

    99E-3 JUNI 2014

    Plattformen

    nungslogik knnen per Code Pushdown vollstndig in die DB verlagert werden. Hierzu schaffen Hana Views, SQL bzw. SQLScript die Voraussetzungen. Hierdurch werden die beiden grten Schwachstellen der Drei-Schichten-Architektur der Flaschenhals zwi-schen Datenbank- und Anwendungs-server sowie die Pufferung der Daten beseitigt.

    Aber auch die Anbindung zum Client hat sich gendert. Der Client (z. B. Web Browser, mobile Device) bernimmt nun die folgenden Aufgaben:

    1. Das UI Rendering auf Basis von SAPUI5 sowie weiteren JavaScript Libraries

    2. Die Verarbeitung von UI Events3. Den Aufbau der Verbindungen

    zum Hana Server via Http(S)

    Der kombinierte App- und Web-Ser-ver fhrt lediglich Kontrollfluss- und Validierungslogik aus und ist fr das Service Enablement zustndig. Hierfr knnen u. a. Server-Side JavaScript oder OData eingesetzt werden. Das Service Enablement regelt und kontrolliert, wie Business-Logik und Daten der Hana DB der Benutzeroberflche bereitgestellt werden, sofern UI Events diese anfor-dern. Die UI Events rufen hierzu auf der Basis des Rest-Paradigmas Services von Hana XS auf.Damit bietet XS aus unserer Sicht zwei entscheidende Vorteile. Erstens: Daten werden nicht mehr zwischen Anwen-dungsserver und Datenbank bertra-gen, die Zeit fr die Datenbertragung entfllt. Zudem erbrigen sich Wartung

    BW Reports zeichnen sich in der Regel durch eine hohe Aggregation der Daten aus. Anwendungsszenarien auf Basis von Hana XS hingegen eignen sich insbe-sondere dann, wenn operative Daten ausgewertet und ein hoher Detaillierungs-grad der Reports gewnscht ist. Exemplarisch haben wir einen Business Case mit Hana XS und SAPUI5 umgesetzt. Die Idee des Business Cases ist es, kontinuier-lich und in groem Umfang anfallende Daten (z. B. Energieverbrauch, Durchsatz-kennzahlen von Maschinen, Strungs- und Statusmeldungen, Bestandszahlen ) von geografisch verteilten Werken oder Anlagen mit einem modernen Frontend zu visualisieren. Hierzu setzen wir Progressbars, Panels, Tabellen, Diagramme u. v. m. ein. Der Business Case wird auerdem durch die Einbindung der Google Maps Library weiter aufgewertet. Die einzelnen Standorte werden mit zustzli-chen Detailinformationen (Bilder, Adressen, Verbrauchszahlen) abgebildet. Ge-rade hier zeigen sich die Vorteile des offenen Konzepts von Hana XS. Externe Libraries wie Google Maps lassen sich in SAPUI5 mit JavaScript entsprechend einfach integrieren. Zudem lsst sich dieses Beispiel auf die unterschiedlichsten Anwendungsbereiche bertragen wie z. B. Supply Chain Ma-nagement, CRM, Sales, MM, EWM, PM.

    Mehr Informationen zu dem Praxisszenario erhalten Sie im Video, das Sie unter folgendem Link aufrufen knnen:www.contrimo.com/services/ueberblick-taetigkeitsfelder/sap-hana-2/sap-hana-xs-video

    Bitte beachten Sie auch denCommunity-Info-Eintrag ab Seite 115

    Marco Harpenschlger ist Bereichs-leiter Business Intelligence bei Con-trimo. Der studierte Wirtschafts-informatiker arbeitet seit mehr als zehn Jahren im SAP-Umfeld. Sein Schwerpunkt ist die Konzeption und Einfhrung moderner Business-In-telligence- und Business-Warehouse-Architekturen und -Anwendungen.

    SAP Hana XS Praxisszenario

    und Kosten fr einen externen Server. Zweitens: UI Rendering sowie UI Events mssen nicht an den Anwendungsser-ver gesendet werden, da diese Aufga-ben jetzt der Client direkt bernimmt. Die Darstellung erfolgt somit individu-ell fr jeden Client.

    Technologie

    Verbindet sich ein Client mit dem Hana- Server, werden folgende Schritte auf Betriebssystemebene ausgefhrt: Eine eingehende Http-Verbindung wird von drei Prozessen verarbeitet. Der Internet Communication Manager entspricht dem Web-Server, der XS-Engine-Pro-zess dem Application-Server und der Index-Server-Prozess reprsentiert die Hana DB selbst. Er stellt den wichtigs-ten Betriebssystemprozess der Hana DB dar, denn ihm wird der Speicherbe-reich, in dem die Daten des In-memory Stores gespeichert sind, zugeordnet. Der XS-Engine-Prozess erweitert den Index-Server-Prozess, entsprechend arbeiten beide Prozesse mit denselben Hana-nativen Datentypen. Daraus re-sultiert eine effiziente Datenverarbei-tung, da weder Daten durch ein Netz-werk gesendet werden (Verarbeitung auf Betriebssystemebene) noch Daten-konvertierungen zwischen Datenbank und Anwendungsserver stattfinden.

    Server-Side JavaScript

    Die Kommunikation zwischen Client und Server basiert auf dem REST-Para-digma. In der XS Engine laufen die REST-Services, die mit dem OData Frame-work oder mit Server-Side JavaScript

    (XSJS) entwickelt werden knnen. Auch wenn seit SP7 eine kundenspezifische Validierungslogik implementiert wer-den kann, eignet sich OData eher fr einfache Services. Um eigenstndige REST-Services zu entwickeln, sollte auf die primre Anwendungsentwicklungs-sprache der XS Engine zurckgegriffen werden Server-Side JavaScript. Neben der Validierungslogik sind die schnelle-re Ausfhrung im Vergleich zu OData und die einheitliche Programmierspra-che fr Server und Client weitere Vor-teile. Hierbei wird Client-Side JavaScript eingesetzt, um die XS Services aufzuru-fen. Als Java VM nutzt die Hana XS En-gine Mozilla SpiderMonkey. Zustzlich sind die Hana-Datentypen sowie Ha-na-native APIs integriert. Im Wesentli-chen werden die APIs genutzt, um die Programmablufe und die Verbindung zwischen Datenbank und XS zu steu-ern. Dies sind beispielsweise Updates, Inserts oder Upserts. Weiterhin knnen Entwickler mit den APIs u. a. auf Http Request und Response-Objekte zu-greifen und diese manipulieren. Auer-dem besteht die Mglichkeit, wieder-verwendbaren Programmcode in XSJS Library Files (.xsjslib) zu schreiben, um dann diese Bibliotheksdatei-en in XSJS-Dateien per $import-Syntax einzu-binden.