Implementierung des Orion Server API auf der SAP-HANA-Plattform

Eclipse Orion meets SAP HANA

Wolfgang Pfeifer, Mo Unewisse
© Shutterstock/Kirill__M

Der Erfolg einer Plattform hängt heute immer mehr davon ab, wie attraktiv diese für Entwickler ist. Offenheit und Einfachheit sind dabei wichtige Faktoren. Um zugängliche Entwicklertools bereitzustellen, wurde das Orion/Server API auf der Plattform SAP HANA implementiert.

Developers are the new kingmakers – das gilt insbesondere für den Erfolg einer Plattform. iOS und Android sind auch deshalb so erfolgreich, weil sie es geschafft haben, eine große App-Entwicklercommunity für sich zu gewinnen, die für diese Plattformen Applikationen entwickeln.

Ein ähnlicher Trend wird auch im Enterprise-Software- und Datenbankbereich immer sichtbarer: Es geht nicht allein um eine vom Hersteller fertig gelieferte Software, sondern auch um Plattformen, auf denen die interne IT und unabhängige Softwareproduzenten ihre Lösungen entwickeln, anbieten und betreiben können.

SAP HANA ist SAPs strategische Plattform, um geschäftskritische Echtzeitapplikationen zu entwickeln. Neben den eigenen, auf HANA basierenden Produkten setzt SAP darauf, dass eine möglichst große Zahl von Entwicklern Lösungen für die HANA-Plattform entwickeln. Eine Erfahrung, die wir ziemlich schnell gemacht haben, ist, dass Entwickler neben den „offiziellen“ mitgelieferten Tools auch gerne die Tools ihrer Wahl verwenden wollen, die sie evtl. schon in anderen Umgebungen verwendet haben. Um dies zu ermöglichen, verfolgte unser Entwicklungsteam das Ziel, ein API anzubieten, das es ihnen ermöglicht, bestehende Tools zu erweitern oder neue Tools an der Plattform anzuschließen. SAP setzt dazu auf das Eclipse Orion/Server API. Es definiert mehrere Subinterfaces für das Arbeiten mit verschiedenen Entwicklungsartefakten, wie zum Beispiel ein File- oder Projekt-API. Auf dieser Basis wurden für die SAP-HANA-Plattform einige dieser Sub-APIs implementiert und erweitert, wo dies notwendig war.

Out of the box ermöglicht HANA die native Anwendungsentwicklung über das HANA Studio, eine auf Eclipse basierende Entwicklungsumgebung, und die Web-IDE – eine webbasierte Entwicklungsumgebung, die es ermöglicht, komplette Applikationen nur über den Browser zu entwickeln. Neben diesen beiden Entwicklungstools soll es dem Entwickler möglichst leicht gemacht werden, auch andere Tools seiner Wahl (z. B. Sublime, Orion) verwenden zu können und sie gegebenenfalls für die Verwendung mit SAP HANA zu optimieren. All diese Tools können über das Orion-kompatible SAP-HANA-REST-API auf die Entwicklungsartefakte in der HANA-Datenbank zugreifen (Abb. 1).

Abb. 1: Mit unterschiedlichen Entwicklungstools lässt sich direkt auf SAP HANA entwickeln

Eclipse Orion

Eclipse Orion ist ein Projekt der Eclipse Foundation mit dem Ziel, „Tools für das Web, im Web“ zur Verfügung zu stellen. Eclipse Orion ist kein monolithischer Block, sondern besteht aus unterschiedlichen Modulen sowie einer klaren Trennung von Client- und Serverseite. Die Offenheit erlaubt ganz unterschiedliche Szenarien und Wiederverwendungen. So wird zum Beispiel der Orion Editor im Firefox Browser verwendet. Die Orion-Web-IDE ermöglicht es, die Entwicklung über einen Browser direkt auf einem Rasperry Pi durchzuführen. Bisher gab es schon zwei Implementierungen der Orion-Serverseite, eine basierend auf Eclipse (in Java geschrieben) und eine Node.js-Variante.

In diesem Sinne stellt die Implementierung des API auf SAP HANA die dritte Plattform dar, auf der die Orion-IDE installiert werden kann, wie in Abbildung 2 zu sehen ist.

Abb. 2: Eclipse Orion 5, auf einem HANA-System deployt

Darüber hinaus verwendet SAP Komponenten von Eclipse Orion im Rahmen der SAP HANA Cloud. Die oben erwähnte Web-IDE verwendet die Compare-Komponente.

Was ist SAP HANA?

Die SAP HANA Data Platform ist in ihrem Kern eine In-Memory-Datenbank, bei der die Tabellen zeilen- oder spaltenweise organisiert werden können. Durch Datenzugriff in Echtzeit und Tabellenorganisation erreicht SAP HANA eine sehr hohe Performanz und Kompressionsrate. Neben der Steigerung der Performanz ist Vereinfachung ein weiteres Ziel. Durch die oben genannten Eigenschaften ist es möglich, transaktionale und analytische Anwendungen von der gleichen Datenbank zu bedienen. Eine Trennung in explizite OLTP- (z. B. ein ERP-System) und OLAP-Anwendungen (zum Beispiel ein Data Warehouse) ist nicht mehr notwendig.

SAP HANA kann wie eine klassische Datenbank verwendet werden und bietet dafür Zugriff über ODBC und JDBC an. Darüber hinaus integriert SAP HANA auch zusätzliche Services, die es ermöglichen, vollständige Applikationen auf der Plattform zu entwickeln – d. h. ohne die Notwendigkeit, zusätzliche Applikationsserver oder Webserver verwenden zu müssen. Ein wesentlicher Service hierfür ist die XS Engine, ein Webserver, der es Entwicklern ermöglicht, client- wie serverseitig Anwendungen in JavaScript zu entwickeln. Die einzelnen Artefakte („Files“) werden dabei nicht auf einem Filesystem gespeichert, sondern direkt in der Datenbank. Der Zugriff auf diese Artefakte erfolgt über das so genannte Repository, das für den sicheren Zugriff und die Versionsverwaltung des Inhalts verantwortlich ist.

Die hier besprochene Orion/Server-API-Implementierung ist genau solch eine Anwendung, die innerhalb der XS Engine läuft und den Inhalt des Repositorys über das Orion-API und HTTP zur Verfügung stellt. Erste Schritte mit SAP HANA können in der HANA Cloud gemacht werden.

SAP-HANA-Rest-API

Wie oben beschrieben, wurden folgende Unter-APIs des Orion/Server API implementiert:

  • Das File-API: API, um auf Files und Verzeichnisse zugreifen zu können.
  • Das Workspace-API: API, um Projekte und Workspaces verwalten zu können.
  • Das Import/Export-API: API, um im Batchmode Files oder Directories mit einem anderen Server oder Client austauschen zu können.
  • Da SAP HANA eine Datenbank umfasst, wurde mit dem Catalog-API, das den Zugriff auf Katalogdaten der Datenbank ermöglicht, ein weiteres API hinzugefügt, das nicht über das Orion/Server API spezifiziert ist, aber den dortigen Regeln folgt.

Ein Designziel war es, die Implementierung kompatibel zum Orion-API zu halten, aber auch SAP-HANA-spezifische Anforderungen realisieren zu können. So wurden die bestehenden APIs an einigen Stellen durch Erweiterungsmechanismen, die weiter unten genauer beschrieben werden, ergänzt.

Das Orion-API ist REST-basiert, d. h. alle Artefakte, auf die dieses API zugreift, werden als Ressourcen dargestellt, auf denen mittels HTTP-Standard-Methoden (GET, PUT, POST, DELETE) zugegriffen wird. Tabelle 1 zeigt die Aktionen, die durch die verschiedenen Methoden auf die Ressourcen angewandt werden.

Tabelle 1: Implementierung der verschiedenen HTTP-Methoden in den verschiedenen APIs

Aufmacherbild: Robot with application programming interface sign. Technology concept. Isolated on white background von Shutterstock / Urheberrecht: Kirill__M [ header = Seite 2: File-API ]

File-API

Aus technischer Sicht gibt es innerhalb des HANA Repositorys keine Files und Directories. Die Ressourcen sind in der Datenbank gesichert. Das File-API bietet Services, um auf diesen Ressourcen wie auf einem Filesystem arbeiten zu können. Es erlaubt das Anlegen, Ändern, Löschen von Ressourcen, aber auch das Kopieren von ganzen Verzeichnisbäumen. Listing 1 und 2 zeigen zusammen, wie ein „minimaler“ Editor Teile dieses API verwenden kann, sofern sie auf einer XS Engine installiert würden.

<!doctype html>
<html>
  <head>
    <title>Orion Editor Sample</title>
    <link rel="stylesheet" type="text/css" href="ht tp://eclipse.org/orion/editor/releases/4.0/built-editor.css"/>
    <script src="ht tp://eclipse.org/orion/editor/releases/4.0/built-editor.min.js"></script>
    <script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
    <script src="mineditor.js"></script>
  </head>
  <body>
    <pre class="editor" data-editor-lang="html"  style="width: 100%; height: 440px;">
</pre>
    <button id="saveButton">Save</button>
  </body>
</html>
require(["orion/editor/edit"], function(edit) {
    var editor, xcsrfToken, path;

    function getURLParameter(name) {
      return decodeURI(
        (RegExp(name + '=' + '(.+?)(&|$)').exec(location.search) || [, null])[1]
      );
    }

    function getSecurityToken() {
      $.ajax({
          url: "/sap/hana/xs/dt/base/server/csrf.xsjs",
          type: 'HEAD',
          headers: {
            "X-CSRF-Token": "Fetch"
          },
          success: function(data, textStatus, xhr) {
            xcsrfToken = xhr.getResponseHeader("X-CSRF-Token");
          }
      });
    }
  
    function saveFile() {
      $.ajax({
          url: "/sap/hana/xs/dt/base/file/" + path,
          type: 'PUT',
          data: editor.getTextView().getText(),
          headers: {
            "X-CSRF-Token": xcsrfToken
          },
          success: function() {
            alert("saved successfully");
          },
      });
    }

    getSecurityToken();
    path = getURLParameter("path");
$.get("/sap/hana/xs/dt/base/file/" + path, function(data) {
        $('.editor').text(data);
        editor = edit({className: "editor"})[0];
    });
    $('#saveButton').click(saveFile);
});

Project/Workspace-API

Dieses API stellt die Funktionen zum Anlegen, Ändern, Löschen und natürlich zum Abfragen auf Informationen zu den Entitäten Workspace und Project bereit. Diese sind ebenfalls implementiert und ermöglichen einem Orion-kompatiblen Client, sich an der HANA-Plattform anzumelden und mit ihr zu interagieren wie mit einem normalen Orion-Server, wie zum Beispiel mit dem, der zu Testzwecken im Orion-Projekt verwendet wird. In einer nativen HANA-Umgebung gibt es kein Workspace-Konzept, da es sich dabei um eine Entität handelt, die normalerweise ausschließlich auf der lokalen Maschine des Entwicklers existiert. Im Fall der API-Implementierung wird der Workspace nutzerspezifisch emuliert. Das Orion-Projektkonzept wurde auf das Paketkonzept der nativen HANA-Umgebung abgebildet und ermöglicht das Anlegen von Orion-Projekten und XS-Applikationen über einfache REST-Kommandos.

Extensibility und Liquid Signature

Nicht alle HANA-Konzepte ließen sich 1:1 auf die API-Spezifikationen abbilden. Um diese Features trotzdem anbieten zu können, musste das API an einigen Stellen erweitert bzw. angepasst werden. Da die in der HANA-Plattform bereitgestellte Funktionalität in einigen Bereichen signifikant über die im Orion-API spezifizierte hinausgeht, mussten wir eine Möglichkeit finden, diese über die gleichen URLs und HTTP-Verben bereitzustellen, um den Aufwand bei der Verwendung in Grenzen zu halten. Hier kamen uns die Flexibilität sowohl von JavaScript als auch HTTP REST entgegen. Wir lösten das Problem, indem wir zwar die in der Spezifikation definierten Interfaces beibehielten, dies aber durch einen Signaturzusatz erweiterten. Dieser wird wie ein Rucksack auf das bestehende API geschnallt. Deshalb auch die Bezeichnung SAPBackPack. Der Parameter wird im HTTP-Header gesetzt und kann eine beliebige Anzahl von Attributen unterschiedlichen Typs und unterschiedlicher Komplexität tragen.

Clients, die diese Signatur im Standard konsumieren, liefern diese natürlich nicht. Die Implementierung ist aber ausreichend robust, um diese weggelassenen Elemente zu verkraften. Zur Laufzeit hat das keine Auswirkungen. Natürliche enthält auch der Response Segmente, die in der Orion-Spezifikation nicht vorkommen.

Templates

Über das API lassen sich Mustache-Templates instanziieren. Die Mustache-JavaScript-Implementierung wurde dafür auf serverseitiges HANA-JavaScript portiert und liegt als Library vor. Man kann über die angebotene Funktionalität sowohl einzelne Templatefiles instanziieren, diese danach im Repository ablegen als auch komplette Paketstrukturen samt Inhalt an die gewünschte Location kopieren. Dabei können sowohl Objektnamen als auch Inhalte Platzhalter enthalten, die durch die gesendeten Parameter ersetzt werden.

Unterstützung für Autovervollständigung und Search

Über einen eigenen Accesspoint (/metadata), der nicht in der Orion-Spezifikation enthalten ist, werden Services zur Existenzprüfung und zur musterbasierten Suche von Objekten sowohl in der Runtime (TABLES, VIEWS, PROCEDURES u. Ä.) als auch Designtime angeboten. Im Wesentlichen wurden diese Dienste zur Unterstützung von Autovervollständigungsszenarien sowohl in Eclipse- als auch in webbasierten Editoren implementiert. Verschiedene Suchszenarien sind bereits möglich (genaue Übereinstimmung, enthält Muster, Berücksichtigung von Groß-und Kleinschreibung). Die Anzahl der Suchtreffer kann begrenzt werden. Das Suchergebnis enthält eine balancierte Verteilung von Treffern über die Objekttypen hinweg.

Massenfähigkeit

Die Orion-Spezifikation an sich definiert eine Interaktion mit einzelnen Objekten, was bei der Verarbeitung von größeren Objektmengen eine hohe Anzahl von Roundtrips verursacht. Wir haben an verschiedenen Stellen sowohl der existierenden APIs (File, Workspace) als auch an den von uns separat erzeugten einige Optimierungen eingeführt. Diese verbessern die Massenfähigkeit, indem sie die gewünschte Funktionalität in einem Roundtrip anbieten und den Einfluss der Netzwerklatenz auf ein Mindestmaß reduzieren. Das gilt für alle GET-, POST-, PUT– und DELETE-Implementierungen, die Dateien und Pakete anlegen, ändern, aktivieren, löschen und lesen. So stellt das Interface zum Beispiel einen Service zum Löschen von Paketen samt Inhalt in einem Request bereit. Die Rückgabewerte und Fehlermeldungen sind diesem Verhalten angepasst.

Security

Die bereitgestellte Funktionalität ist komplett benutzerspezifisch, was den Zugriff auf Objekte und deren Inhalt betrifft. Das gilt sowohl für die in der Orion-Spezifikation definierten Services als auch für die von uns hinzugefügten. Es gilt für alle Objekte, unabhängig davon, ob sie in der Designtime (HANA Repository) oder in einer der im Zugriff befindlichen Runtimes (z. B. DB Runtime Catalog) lokalisiert sind. Ein Benutzer kann nur gemäß seinen Zugriffsrechten mit Objekten arbeiten bzw. diese überhaupt sehen. Zum Betrieb des Interface wird eine Rolle mitgeliefert, die der Werkzeughersteller in seine Rolle aufnimmt, um dem Nutzer die Möglichkeit zu geben, das API zu verwenden. Modifizierende Zugriffe sind zusätzlich durch ein entsprechendes Token gegen Cross-Site Scripting gesichert. Das API enthält einen Service zur Erzeugung eines derartigen Token.

Aktuelle Einsatzszenarien

Webbasierte Tools: Werkzeuge, die browserbasiert operieren (HANA-Web-IDE), benutzen das API in größerem Umfang. Das Interaktionsmuster ist im Wesentlichen feingranular. Operationen werden in der Regel auf einer Datei ausgeführt. Das Massenszenario ist eher selten, wird jedoch unterstützt.

Eclipse-basierte Tools: Die Nutzung des APIs bietet hier u. a. den Vorteil des HTTP-basierten Zugriffs auf das HANA-Backend, unabhängig davon, ob die HANA-Instanz im Intranet oder in der Cloud betrieben wird und deshalb über das Internet erreicht werden muss. Darüber hinaus wird das API in Eclipse-basierten Szenarien verwendet, bei denen die Massenoperationen verwendet werden, um das lokale Filesystem regelmäßig mit dem HANA-Backend zu synchronisieren. Das gilt nicht für die Services, die für die Unterstützung von Autovervollständigung und Search angeboten werden. Hier erfolgt ein direkter Zugriff auf die Metadaten der jeweiligen Objekte im HANA-Backend aus den Tools/Editoren.

Fazit

Durch die Umsetzung der Orion-Spezifikation in unserem serverbasierten API hoffen wir, die nötige Offenheit bieten zu können, die eine einfache Integration mit Werkzeugen aller Art ermöglicht. Andererseits haben wir den Standard dort erweitert, wo es notwendig war, Funktionalität unserer Infrastruktur nach außen zu exponieren und Lücken in der Spezifikation zu schließen (Suche, Massenfähigkeit der Services, Sicherheitsaspekte). Ob die gewählte Kombination gelungen ist, wird die Zukunft zeigen – in der hoffentlich eine große Anzahl interner und externer Werkzeugbauer diese Schnittstelle verwenden.

Geschrieben von
Wolfgang Pfeifer
Wolfgang Pfeifer
Wolfgang Pfeifer arbeitet als Architekt in der SAP-HANA-Core-Entwicklung und ist insbesondere für das SAP-HANA-Rest-API verantwortlich.
Mo Unewisse
Mo Unewisse
Mo Unewisse arbeitet als Architekt in der SAP-HANA-Core-Entwicklung. Sein besonderer Fokus liegt dabei auf der Vereinfachung der Softwareentwicklung.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: