OpenUI5

Vorstellung des JavaScript Frameworks SAPUI5

Unser Software Engineer Björn ist JavaScript-Experte und unterstützte 2015 verschiedene SAPUI5-Projekte eines Automobilherstellers und eines Netzbetreibers. Björn gibt uns in diesem Beitrag einen kurzen Überblick zur Leistungsfähigkeit des Toolkits SAPUI5 der SAP SE, dem führenden Softwarehersteller für Business-Software.

Die Entstehungsgeschichte von SAPUI5

Im Jahr 2012 veröffentlichte der Standardsoftwarehersteller SAP das UI Development Toolkit for HTML5, kurz SAPUI5. Es handelt sich um eine browserbasierte UI-Technologie basierend auf HTML5, CSS3, JavaScript und der allgegenwärtigen JavaScript-Bibliothek jQuery, die von SAP mit folgenden Worten charakterisiert wird:

Bei der SAPUI5-Laufzeit handelt es sich um eine Client-seitige HTML5-Rendering-Bibliothek, die eine Palette von Standard- und Erweiterungscontrols sowie ein leichtgewichtiges Programmierungsmodell zur Verfügung stellt. Sie können diese Controls erweitern sowie neue Custom-Controls entwickeln.

Seit Ende 2013 sind die meisten Teile des SAPUI5-Toolkit als Open-Source-Variante OpenUI5 erhältlich, womit SAP sich die große Community der Web-Entwickler erschließt.

SAPUI5 bietet eine als feature-rich bezeichnete Kernbibliothek. Diese ermöglicht eine klare Trennung der Verantwortlichkeiten nach dem Model-View-Controller-Paradigma: Es erfolgt ein Data-Binding von Models an die Controls im View. Letzterer wird idealerweise deklarativ erstellt, wie weiter unten vorgestellt.

Zu jedem View existiert ein Controller, der selbst mehrere Views unterstützen kann. Abgerundet wird die Kernbibliothek durch Funktionalitäten wie die vereinfachte Unterstützung von Klassenhierarchien nach dem Prototyp-Konzept von JavaScript und das Laden von lokalisierten Textdateien.

Auf die Kernbibliothek aufbauend existiert eine große Palette an ausgelieferten UI-Controls, Anfang 2015 belief sich die Anzahl auf etwa 200. Out-of-the-box unterstützen diese ein Standard Theme für ein einheitliches Look-And-Feel, Animationen, Barrierefreiheit, Touch-Bedienung und Rechts-nach-links-Sprachen.

Nach einem Seitenhieb „SAP, ehemals als die Vorhölle der User Interfaces bekannt“ (Java Magazin 01/2016, Editorial S. 3) lobte das Java Magazin kürzlich die neue Technologie, die Design und Nutzerinteraktion für Business-Apps auf verschiedenen Geräten regelte.

Das Model

Models sind Instanzen von sap.ui.model.Model, die über Data Binding an Controls gehängt werden können. Haupteigenschaft dieser Klasse ist, dass Änderungen der Daten des Models propagiert werden, woraufhin die Adressaten des Binding reagieren können.

Gängig ist die Nutzung eines JSON-Models, dessen Daten beliebig programmatisch manipuliert oder initial von einer URL mit JSON-Response gefüllt werden können.

Models können an ein Control, einen View oder die Applikation gehängt werden, optional unter Angabe eines Namens. Beim Data Binding wird das in der Hierarchie nächstliegende Model genutzt, das dem Namen entspricht.

Beispielsweise kann ein Controller eines Views in selbigen ein unbenanntes Model hängen, das nur Einstellungen oder Bewegungsdaten dieses Views beziffert, während an der Applikation zum Beispiel anwendungsweite Konfigurationsdaten in einem Model namens config bereitgestellt werden.

Die View

Ein SAPUI5 View ist eine Ansammlung von Controls einer Bildschirmmaske. Die Models werden über Data Binding an die Controls der View und der View selbst verbunden. Über das Data Binding werden die Änderungen zwischen dem Model und der verbunden View automatisch aktualisiert.

Das Data-Binding kann über verschiedenen Wege erfolgen, entweder programmatisch als JavaScript-View, als HTML-View oder deklarativ als XML-View. Ich bevorzuge die deklarative Definition als XML-View. Dem nachfolgenden Listing 1 kann man die Trennung zwischen View und Controller sehr gut erkennen.

Listing 1: Beispielhafter XML-View

<core:View controllerName="com.example.view.main.MainMenu" xmlns="sap.m" xmlns:exmp="com.example.control" xmlns:core="sap.ui.core">
 <Page enableScrolling="true" class="exmplPage exmplMainMenu" showNavButton="false">
 <customHeader>
 <exmp:PageHeader id="pageHeader" pageTitle="{i18n>MainMenu.header.title}"
 backButtonVisible="false" mainMenuButtonVisible="false" infoButtonVisible="false" confMsgVisible="false"
 userInfoButtonVisible="{appSettings>/multipleUserRoles}" userInfoPress="openRoleSelectionDialog"/>
 </customHeader>
 <VBox alignItems="End" class="exmplWdsSwitch" visible="{wds>/visible}">
 <HBox alignItems="Center">
 <Label text="{i18n>MainMenu.wds.mode}"/>
 <Switch state="{wds>/enabled}" change="changeWdsMode"/>
 </HBox>

Eigenschaften eines XML-Views:

  1. Über herkömmliche XML-Syntax werden Typ und Eigenschaften des Controls angegeben. Der Namensraum entspricht dem Package. Ein weiterer Vorteil ist, dass auf diesem Weg eigenentwickelte Controls angegeben werden können.
  2. Notation in geschweiften Klammern, um ein Attribut eines Controls über das Data-Binding zu verbinden: Der XML-Ausdruck <Switch state=“{wds>/enabled}“ überträgt den Inhalt des Feldes enabled aus dem Model wds in die Eigenschaft state eines Controls vom Typ Switch.
  3. Aggregationen sind Kind-Elemente von Controls. Beispielsweise bietet die sap.m.VBox die Aggregation items, die beliebige Controls aufnehmen kann. Beim Rendern werden diese Controls in der Box untereinander angeordnet.
  4. Einerseits können die Kind-Elemente fix in der XML-Datei angegeben werden. Sehr viel häufiger gibt es vermutlich den Fall, dass die Daten der Elemente aus einer Liste in einem Model gespeist werden. Kommen Listenelemente hinzu, werden automatisch mehr entsprechende Kindelemente im View gerendert.
  5. Im XML-Tag <Switch state=“{wds>/enabled}“ change=“changeWdsMode“/> bezieht sich das zweite Attribut auf einen Event-Handler. changeWdsMode ist eine Funktion im Controller, die mit einem Event-Objekt aufgerufen wird, wenn der Anwender den Status des Controls ändert.

Der Controller

Im Controller ist das Verhalten des Views implementiert. Jeder Controller implementiert optionale Lifecycle-Methoden, von denen onInit und onBeforeRendering am gebräuchlichsten sind. Es folgen die Event-Handler- und Formatierer-Funktionen, die der oder die assoziierten Views erfordern.

Listing 2: Beispielhafte Controller-Klasse

jQuery.sap.require("com.example.BasePageController");
jQuery.sap.require("com.example.util.OrgUnits");
jQuery.sap.declare("com.example.view.main.MainMenu");
com.example.BasePageController.extend("com.example.view.main.MainMenu", {
 onInit: function(evt) {
 this.getView().setModel(sap.ui.getCore().getModel("tileGroups"), "tileGroups");
 this.getView().setModel(sap.ui.getCore().getModel("wds"), "wds");
 },
 openRoleSelectionDialog: function() {
 ExampleStatics.appController.openRoleSelectionDialog();
 },

Nutzt man die deklarative XML-View Beschreibung, wird der Klassenname des Controllers im Kopf der View angegeben. Das Toolkit instanziiert pro View einen Controller, der in einer entsprechend benannten Datei vorliegen muss.

Wie in Listing 2 ersichtlich, können Abhängigkeiten synchron eingebunden werden. Optional wird der Controller von einer bestehenden Klasse abgeleitet, um redundante Code-Strecken in Basisklassen zu bündeln.

Der Test

Als Unit-Test-Framework ist in SAPUI5 QUnit vorgesehen. Auch modernere Kandidaten sind einsetzbar, zum Beispiel Mocha.

Zur Unterstützung der Testimplementierung bietet das Toolkit die Klasse sap.ui.core.util.MockServer, mit der das Backend simuliert werden kann. Im einfachsten Fall liefert eine solche Mock-Instanz fix JSON-Dateien als Antwort, programmatisch können aber auch parametrisierte GET- sowie POST-, PUT- und DELETE-Requests behandelt werden.

Der Mock-Server wird idealerweise auch im Rahmen der One Page Acceptance Tests genutzt, kurz OPA5. Dieses Framework für Akzeptanztests berücksichtigt, dass UI5-Anwendungen Single-Page-Applications mit Verzögerungen im Seitenaufbau durch Animationen und Data-Binding sind. Eine beispielhafte Ausführung der OPA-Tests ist in Abbildung 1 dargestellt.

Ausführung des Akzeptanztests

Abbildung 1: Ausführung der Akzeptanztests

Die Tools

Seit langem existieren Plugins für die Eclipse IDE, mit denen Anwendungen leicht auf einen NetWeaver deployed werden können. Alternativ zu Eclipse und NetWeaver können Tools aus dem JavaScript-Ökosystem verwendet werden. Speziell für das Build-Management-Framework Grunt veröffentlichte SAP entsprechende Plugins.

Die Dokumentation

Das offizielle Dokumentationsportal stellt die API-Referenz von SAPUI5 in einem Umfang bereit, wie man das bisher von SAP-Produkten nicht kannte. Hervorzuheben ist der Entwicklerleitfaden. In diesem findet man zu jedem der rund 200 Controls eine Beispielanwendung mit Code-Schnipseln.

Die Quellen der Open-Source-Variante OpenUI5 finden sich auf GitHub.

Bei traditionellen SAP-Produkten war das SAP Community Network die primäre Quelle für Hilfe. Unter den Tags sapui5 oder openui5 findet man diese inzwischen auch auf Stackoverflow.

Die Zukunft von SAPUI5

SAP hat UI5 als strategische Frontend-Technologie für künftige Produkte auserkoren, um die Benutzer auf unterschiedlichen Gerätetypen zu erreichen. Unter dem Namen Fiori veröffentlicht der Konzern Applikationen, die alternative Benutzeroberflächen für Anwendungen der traditionellen SAP-Systeme bieten.

In der neuen Produktlinie Simple for HANA, die auf der SAP-eigenen In-Memory-Datenbank HANA aufsetzt, ist SAPUI5 die führende Oberflächentechnologie. Über die Open-Source-Variante ist das Toolkit allerdings auch für Nicht-SAP-Applikationen einsetzbar. Wegen des großen Repertoires an Controls halte ich es sogar für eine erwägenswerte Alternative von Angular.