Sie sind auf Seite 1von 34

APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

1
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

INHALT
ÜBER DEN AUTOR 3
1 WARUM APPS? 4
1.1 Apps im Enterprise Context 4
2 SAP FIORI 5
2.1 Neue Designsprache und Philosophie 6
3 UI5 7
3.1 SAPUI5 / OpenUI5 8
3.2 Kompatibilitätsregeln 8
3.3 Browser und Platform Support 13
3.4 Architektur 14
3.5 Entwicklungsumgebung 15
3.6 Model View Control 18
3.7 Was sind eigentlich UI Controls? 20
3.8 Datenbindung 22
3.9 Fragmente 24
3.10 Automatisiertes Testen 25
4 OPEN DATA PROTOCOL (ODATA) 26
4.1 Service-Implementierung 29
4.2 Erstellen eines OData-Services 30
4.3 API Management mit Postman 32
5 EXKURS FIORI MENTOR APP 32
MISSION MOBILE – DIE EXPERTEN FÜR MOBILE APPS IM
SAP UMFELD 34

2
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

ÜBER DEN AUTOR

Rico Magnucki (M. Sc. naturw. Informatik)


Fachbereichsleiter Mission Mobile

Mein Schwerpunkt liegt in der Entwicklung von Mobility Strategien im


Bereich SAP Fiori und darüber Hinaus. Des Weiteren verfüge ich über
tiefgehende Erfahrungen im Bereich der Mensch-Maschine-Interaktion.
Gerne unterstütze ich Sie bei dem Design und der Konzeptionen von
mobilen Anwendungen und optimiere diese mit Ihnen auf den jeweili-
gen Anwendungsfall.

Neben den Strategischen Themen beschäftige ich mich mit der Kon-
zeption von mobilen Szenarien, in denen eine Verbindung zum Internet
nicht sichergestellt werden kann und setze diese mit meinem Team um.

3
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

1 WARUM APPS?
Ob Hotelbuchung, Wetterabfrage oder Taxiruf – für nahezu alles gibt
es inzwischen eine App. Knapp ein Drittel aller Smartphone-Besitzer in
Deutschland hat auf seinem Gerät zwischen 11 und 20 mobile Anwen-
dungen installiert, knapp 17 % sogar über 31 (Quelle: de.statista.com).
Auch im Geschäftsleben ist man heute nicht mehr an den PC gefesselt,
sondern erledigt seine Aufgaben per Smartphone, Tablet oder Note-
book von überall aus. Mobilität heißt dabei: Nicht nur der Mensch ist
beweglich, sondern auch die Daten. Sie lassen sich zwischen Desktop,
Cloud und Tablet beliebig transferieren, um an jeweils richtiger Stelle
zur Verfügung zu stehen.

1.1 APPS IM ENTERPRISE CONTEXT

Nach zögerlichem Start haben sich mobile Enterprise Apps in Unter-


nehmen weltweit durchgesetzt. Diese verfolgen mit ihrem Einsatz zwei
Hauptziele: Verbesserung der Kommunikation zwischen Beschäftigten
und mit Kunden sowie Erhöhung der Produktivität. Deutsche Firmen
liegen hier sogar recht weit vorne, wie eine Studie Adobe Enterprise
Mobile Apps Survey aus dem Jahr 2016 gezeigt hat. Demnach nutzen
weltweit 67 Prozent der befragten Unternehmen solche mobile Anwen-
dungen, mit steigender Tendenz (Deutschland: 75 %). Für sie ist Enter-
prise Mobility (in den Bereichen Messaging und Collaboration, CRM,
Kunden-Service und -Support) mittlerweile ein entscheidender Faktor
des Unternehmenserfolgs – vorausgesetzt, die Themen Sicherheit,
Schutz der Privatsphäre, (Cloud-)Integration und einfache Entwicklung/
Bereitstellung werden ausreichend berücksichtigt.

4
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

2 SAP FIORI
Hohe Produktivität und einfache Kommunikation wünschen sich auch
SAP-Anwender in ihrer täglichen Arbeit. So funktionsreich die ERP-Soft-
ware aus Walldorf ist – für intuitives, einfaches Arbeiten im Sinne o.g.
Ziele stand sie bislang nicht. Traditionell charakteristisch für SAP wa-
ren vor allem die kompliziert zu bedienenden Anwenderoberflächen
(Graphical User Interfaces = GUI). In ihnen muss für jede Aktion, jeden
Prozess eine eigene Transaktion ausgeführt werden. Power User kom-
men damit gut zurecht, ungeübte Gelegenheitsnutzer dagegen taten
sich von jeher schwer.

Um hier eine Trendwende zu schaffen, bedient sich auch SAP seit ei-
niger Zeit der neuen Möglichkeiten aus dem Consumer-Bereich und
schafft für seine Business-Software leicht verständliche und zu be-
dienende Anwenderoberflächen. Das Konzept dahinter heißt SAP Fi-
ori. Über eine Fiori-App können sporadische Nutzer ohne Schulung
oder tiefere SAP-Kenntnisse alltägliche Vorgänge im ERP-, CRM- oder
SRM-System durchführen, zum Beispiel Störungen in der Produktion
und Angebote erfassen, Inventurdaten aufnehmen u.v.m. Die komple-
xen Prozessschritte im SAP-Backend verbergen sich dabei hinter einer
aufgeräumten Oberfläche. In dieser sind vormals einzelne Schritte aus
verschiedenen Transaktionen zu einem Bild verbunden. Oder aber
bisherige umfängliche Transaktionen werden aufgeplittet auf einzel-
ne Apps. Ds reduziert die Komplexität und ermöglicht dem Anwender,
seine Teilaufgaben in einer dem kleinen Bildschirm angemessenen Art
und Weise vorzunehmen. Wie herum man es auch anpackt: Es geht bei
Fiori stets um die vereinfachte Darstellung von Aufgaben, optimiert auf

5
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

mobile Endgeräte. Auf dem Desktop hat SAP dies mit Screen Personas
als separatem Produkt bereits vorexerziert – hier sind mittlerweile auch
Anwendungen im „Fiori“-Stil möglich. Seit 2014 sind Fiori Apps im lizen-
sierten SAP-Leistungsumfang enthalten und können ohne Zusatzkosten
verwendet werden.

Unter https://fioriappslibrary.hana.ondemand.com/sap/fix/externalVie-
wer/ veröffentlicht SAP eine permanent aktualisierte Übersicht derzeit
erhältlicher vorgefertigter Apps. Zu den beliebtesten gehören Anwen-
dungen wie „My Accounts“/„My Contacts“ (Verwaltung von Geschäfts-
kontakten), „My Tasks“ (Aufgabenverwaltung), „My Timesheet“ (Zeitma-
nagement) oder „Create/Change Sales Order“ (Einkaufsübersicht).

SAP Fiori Apps sind auf beliebigen Endgeräten lauffähig und passen sich
dank Responsive Design an die verschiedenen Devices an. Sie ermögli-
chen damit die Arbeit in SAP auch von unterwegs aus, per Smartphone
oder Tablet. Dass dadurch kleinere Aufgaben auch zwischendurch er-
ledigt werden können, sich Warte- und Transferzeiten verkürzen oder
ganz wegfallen, wirkt sich unmittelbar auf eine höhere Produktivität aus.

2.1 NEUE DESIGNSPRACHE UND PHILOSOPHIE

Grundgedanke der neuen Technologie ist die Schaffung eines im Ver-


gleich zu den altbekannten SAP Web Dynpro-Oberflächen völlig neu-
en Designs für das Arbeiten im ERP-System. SAP Fiori ist folglich kein
Produkt im engeren Sinne, sondern lässt sich eher als Design-Konzept
verstehen, das vorgibt, wie Anwendungen zu gestalten und implemen-
tieren sind. Dafür hat SAP seine SAP Fiori Design Guidelines aufgestellt,
die aus folgenden fünf Prinzipien bestehen:

6
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

1. Role-based – Der Anwender erhält genau und nur die Funktionen,


die er für seine spezielle Aufgabe benötigt und die seiner Rolle im
Unternehmen entsprechen.
2. Adaptiv – Apps sind anpassbar an verschiedenste Szenarien und
Endgeräte
3. Coherent – Flüssige und intuitive Bedienung
4. Simple – Alle Funktionen, die nicht unbedingt erforderlich sind,
entfallen.
5. Delightful – Jede App schafft eine emotionale Verbindung
zwischen der zu bewältigenden Aufgabe und dem Anwender.

3 UI5
AnwenderInnen können sowohl Standard-Fiori-Apps individuell ergän-
zen als auch völlig neue Anwendungen zur Prozessautomatisierung kre-
ieren. In vielen Fällen ist dies notwendig, da SAP selbst kaum sämtliche
seiner bislang rund 400.000 Benutzeroberflächen (SAP Dynpros) als Fiori
App nachprogrammieren wird.

Die App-Entwicklung geschieht mit Hilfe von SAPUI5, einem auf HTML5
basierenden OpenSource-Toolset. Mit HTML5 werden Texte und andere
Inhalte elektronischer Dokumente im Internet ausgezeichnet und ver-
netzt. Die Computersprache bietet Funktionen wie Video, Audio, lokalen
Speicher und dynamische 2D- und 3D-Grafiken, ohne dass dafür zu-
sätzliche Plugins (z. B. Adobe Flash) notwendig sind. Das standardisier-
te SAPUI5-Toolset bedient sich offener Web-Standards und beinhaltet
zahlreiche vordefinierte grafische Bedienelemente zum Erstellen neuer
Oberflächen für verschiedenste Prozessschritte in SAP.

7
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

3.1 SAPUI5 / OPENUI5

SAP liefert zwei Ausführung seines Development Toolkits aus: SAPUI5


und die Open-Source Variante OpenUI5. Das JavaScript-Framework Ope-
nUI5 hat SAP unter einer Apache-2.0-Lizenz entwickelt, um betriebs-
systemunabhängige Geschäftsanwendungen zu erstellen. Sein Kernel
basiert auf JavaScript, jQuery und LESS. Die Bibliothek beinhaltet die
MVC-Architekturbausteine mit Optionen für verschiedene Ansichten
und Modellformate. Sie wurde nach mehreren Jahren in der Produktion
bei SAP Ende 2013 als Open Source veröffentlicht; Erweiterungen sind
über GitHub möglich.

SAPUI5 ist quasi eine proprietäre Version von OpenUI5, die integriert ist
in die eigenen Produkte (SAP HANA, SAP Cloud Platform, SAP NetWea-
ver 7.4 oder höher, User Interface Add-on für SAP NetWeaver Applica-
tion Server 7.3x). Anwender erhalten SAPUI5 kostenfrei zur Verfügung
gestellt. Hierfür liefert SAP, anders als bei OpenUI5, auch Bugfixes. Da-
rüber hinaus beinhaltet SAPUI5 einige zusätzliche Komponenten, die in
der freien Version fehlen. Hierbei handelt es sich jedoch größtenteils um
exotische UI-Komponenten – die Standardkomponenten sind in beiden
Versionen vorhanden. Der Kernel ist bei beiden Versionen identisch, die
somit stets den gleichen Entwicklungsstand haben.

3.2 KOMPATIBILITÄTSREGELN

Entwickler von Anwendungen, Funktionen oder Steuerelementen mit


oder für OpenUI5 müssen eine Reihe von Kompatibilitätsregeln beach-
ten. Die Regeln gelten sowohl für die Einführung neuer APIs wie für
inkompatible Änderungen an bestehenden APIs. Wenn im Folgenden

8
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

von API gesprochen wird, bezieht sich dies auf die „Public API“, d.h.
Funktionen, Klassen, Namespaces, Controls mit ihren deklarierten Ei-
genschaften, Aggregationen, etc. Die einzige Definition der öffentlichen
API ist die API-Referenz, die im OpenUI5 Demo Kit enthalten ist. Funk-
tionen, die dort nicht erwähnt werden, sind nicht Bestandteil der API.

• Major Release (x.yyy.zz): Eine neue Major-Version kann neue APIs


einführen oder inkompatible Änderungen an bestehenden APIs
vornehmen.

• Minor release (x.yyy.zz): Eine neue Minor-Version kann neue APIs


einführen, darf aber keine inkompatiblen Änderungen an APIs ent
halten.

• Patch-Release (x.yy.zz): Eine neue Patch-Version enthält nur Fixes


für die bestehende Implementierung, enthält aber in der Regel
keine neuen Features oder inkompatible API-Änderungen.

Kompatible Änderungen

Eine Reihe von Änderungen an bestehenden APIs sind kompatibel und


können jederzeit durchgeführt werden. Dazu zählen das Hinzufügen
neuer Bibliotheken, Steuerelemente, Klassen, Eigenschaften, Funktionen
oder Namensräume, das Verallgemeinern von Eigenschaften, indem
diese in der Vererbungshierarchie nach oben verschoben werden so-
wie das Hinzufügen neuer Werte zu Aufzählungstypen (Dies bedeutet,
dass sich Entwickler bei der Behandlung von Enum-Eigenschaften da-
rauf einstellen müssen, neue Werte zu akzeptieren, z.B. durch die Im-
plementierung eines „default“- oder „otherwise“-Pfades, wenn sie auf
Enum-Werte reagieren).

9
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Inkompatible Änderungen

Nicht Teil der öffentlichen API sind Open-Source-Bibliotheken und Log-


meldungen; sie können sich daher in Patch- und Minor-Releases ändern.

Die folgenden Änderungen an bestehenden APIs sind inkompatibel, kön-


nen aber in einem neuen Major-Release durchgeführt werden:

• Umbenennen einer API (Bibliothek, Namensraum, Funktion, Ei


genschaft, Control, Ereignisse usw.)
• Entfernen der Unterstützung für Parameter
• Entfernen der Unterstützung für Konfigurationseinträge
• Einschränkung der Sichtbarkeit einer API (führt nicht zu einem
Bruch von JavaScript-Anwendungen, sondern ändert den Vertrag).
• Entfernen oder Neuordnen von Parametern in einer API-Signatur
• Reduzierung des akzeptierten Wertebereichs, z.B. Parameter
einer Funktion
• Erweiterung des Wertebereichs eines Rückgabewertes oder einer
Eigenschaft (Ausnahme: Aufzählungen)
• Verschieben von JavaScript-Artefakten (Namespaces, Funktionen,
Klassen)
zwischen Modulen
• Ersetzen von Asserts durch Vorbedingungsprüfungen
• Eigenschaften (etc.) in der Vererbungshierarchie nach unten ver-
schieben
• Ändern des Namens von Enum-Werten
• Ändern von Vorgaben (Eigenschaften, Funktionsparameter)
• Umbenennen oder Entfernen von Dateien

10
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Vererbung

Das Vererben von OpenUI5-Objekten (z.B. durch den Aufruf von sap.
ui.extend auf einem bestehenden Control, um eigene Funktionalität
hinzuzufügen) kann die Updatefähigkeit des Codes gefährden. Beim
Übersteuern einer OpenUI5-Lifecycle-Methode (z.B. init, exit, onBefore-
Rendering, onAfterRendering) muss daher sichergestellt werden, dass
die Superklassenimplementierung aufgerufen wird.

SAP kann jederzeit die interne Implementierung der übergeordneten


Klasse hinzufügen, entfernen oder ändern. Insbesondere auf folgende
Funktionen sollte man sich daher nicht verlassen:

• Interne Strukturen und Methoden, die nicht Teil der öffentlichen


API sind.
• Jede interne Logik und jedes Verhalten des Objekts, das nicht in
der öffentlichen API widergespiegelt wird
• Die übergeordnete Hierarchie von Objekten speziell für Compo
sites, bei denen sich der API-Elternteil vom realen Elternteil unter
scheidet (z.B. Elternobjekt > internes Objekt > untergeordnetes
Objekt)
• Alle Rendering-Funktionen eines Steuerelements, einschließlich
der HTML-Struktur und der CSS-Klassen
• Namenskollisionen mit OpenUI5-Strukturen und -Methoden.
OpenUI5 kann zu einem späteren Zeitpunkt neue APIs oder inter
ne Strukturen einführen, die mit der eigenen Implementierung
kollidieren. Um Kollisionen zu vermeiden, kann ein benutzerde
finiertes Präfix verwendet werden. Namensräume, die mit
sap.m.* oder sap.ui.* in der App beginnen, sind zu vermeiden.

11
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Es empfiehlt sich, geerbte Klassen nach dem Update von OpenUI5 sorg-
fältig zu testen, um sicherzustellen, dass die erweiterte Funktionalität
weiterhin wie erwartet funktioniert.

Abkündigungen

SAP kennzeichnet alte Artefakte in der Regel als solche und erstellt
neue, anstatt inkompatible Änderungen vorzunehmen. Ein Depreca-
tion-Kommentar in der entsprechenden API-Dokumentation oder ggf.
ein Log-Eintrag in der Implementierung erklären, warum und wann ein
Artefakt veraltet ist. Dort finden sich auch Hinweise, wie man dieselben
Ergebnisse erzielen kann, ohne veraltete Funktionalität zu verwenden.

Experimentelle API

Einige Funktionen oder Steuerelemente, die mit der aktuellen Ope-


nUI5-Version ausgeliefert werden, sind als „experimentell“ gekennzeich-
net. Diese sind nicht Bestandteil des freigegebenen Umfangs der mitge-
lieferten OpenUI5-Version und können jederzeit ohne Vorankündigung
und ohne formalen Verwerfungsprozess geändert oder gelöscht wer-
den. Sie können auch inkompatibel zu Änderungen sein, die im Rahmen
eines Upgrades vorgenommen werden. Experimentelle Funktionen oder
Steuerelemente sollten daher nicht in einer produktiven Umgebung
oder mit Daten, die nicht ausreichend gesichert wurden, genutzt wer-
den.

12
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Open-Source-Bibliotheken von Drittanbietern

OpenUI5 enthält und verwendet mehrere Open-Source-Bibliotheken


von Drittanbietern, wie z.B. jQuery. Sie lassen sich auch von Anwen-
dungen und/oder Custom-Control-Bibliotheken verwenden; die hier
beschriebenen OpenUI5-Kompatibilitätsregeln gelten sie für nicht. Wer
solche Bibliotheken, die in OpenUI5 enthalten sind, verwenden möchte,
sollte folgende Einschränkungen beachten:

• SAP entscheidet, welche Versionen und Module der verwendeten


Bibliotheken zur Verfügung gestellt werden.
• SAP kann auch innerhalb eines Patch-Release auf eine höhere
Version der verwendeten Bibliotheken upgraden.
• Aus wichtigen Gründen, wie z.B. Sicherheit, kann OpenUI5 die Be
reitstellung einer Bibliothek jederzeit einstellen.
• Die Bibliotheken von Drittanbietern werden „as is“ zur Verfügung
gestellt. Erweiterungen, Anpassungen und Support werden von
SAP nicht durchgeführt oder bereitgestellt.

3.3 BROWSER UND PLATFORM SUPPORT

Da OpenUI5 auf CSS3, HTML5 und der JavaScript-API von ECMAScript 5


(ES5) basiert, werden nur Browser mit HTML5-Fähigkeiten unterstützt.
Mit iOS-, Android-, MacOS- und Windows befinden sich darunter die
relevanten Plattformen. Generell unterstützt das OpenUI5-Framework
nur Hauptversionen, die auch von der jeweiligen Plattform unterstützt
werden.

13
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

3.4 ARCHITEKTUR

Auf der Client-UI-Technologie OpenUI5 entwickelte Apps laufen im


Browser auf jedem Endgerät. Greift der Anwender auf eine App zu, wird
eine Anfrage an den jeweiligen Server gesendet, um die Anwendung in
den Browser zu laden. Abhängig von der Umgebung, in der OpenUI5
eingesetzt wird, können die Bibliotheken oder Anwendungen z.B. auf
einem SAP NetWeaver Application Server oder einer SAP Cloud Platform
abgelegt werden. Im ersten Fall ist der Betrieb eines SAP Fiori Frontend
Servers als Gateway Voraussetzung. Dieser kommuniziert mit SAP über
OData-Services (s.u.) und rendert die Apps. Soll eine App auch außer-
halb der Unternehmensgrenzen genutzt werden, sollte der Web-Zugriff
auf das SAP Gateway beim On-premise-Betrieb durch einen Reverse
Proxy und eine Web Application Firewall geschützt werden, die in der
demilitarisierten Zone angesiedelt ist.
Die oberste Struktureinheit wird als Bibliothek bezeichnet. Bibliotheken
sind die Master-Artefakte im Erweiterungskonzept. Sie bündeln eine
Reihe von Controls (z.B. Button, Label, TextField oder Table) und ver-
wandten Typen und machen sie für Web-Anwendungen nutzbar. Es gibt
vordefinierte und Standardbibliotheken, wie sap.m, mit vielen häufig
verwendeten Controls.

Ein UI-Element ist der Grundbaustein der Benutzeroberflächen. Dabei


handelt es sich um eine wiederverwendbare Einheit mit Eigenschaften,
Ereignissen, Methoden und Beziehungen. Die wichtigsten Beziehungen
sind Aggregationen zu anderen UI-Elementen, so dass eine Baumstruk-
tur von Elementen erstellt werden kann.

14
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Aus Entwicklersicht die wichtigsten Artefakte sind die Controls, die das
Erscheinungsbild und die Benutzerinteraktion auf dem Bildschirm steu-
ern. Dabei handelt es sich um spezielle Oberflächenelemente, die als
Endknoten (Blätter) einer Baumstruktur verwendet werden können. Auf
diese Weise dient ein Control als Einstiegspunkt, insbesondere für das
Rendering. Neben Controls gibt es noch weitere Nicht-Control-Elemente,
die nicht als Wurzel, sondern nur als abhängiger Teil innerhalb einer
solchen Baumstruktur verwendet werden können (z.B. TableRow, Tab-
leCell).

Datentypen sind First-Class-Entitäten im Metamodell. Dies ermöglicht


die Wiederverwendung von Typen über Bibliotheken hinweg und die
Erweiterbarkeit des Typensystems. Die Kernbibliothek (technisch gese-
hen ist dies die sap.ui.core library) definiert bereits einen Kernsatz von
Typen, die in anderen Bibliotheken verwendet werden können.
(Quelle: https://openui5.hana.ondemand.com/#/topic/ec699e0817fb-
46a0817b0fa276a249f8)

3.5 ENTWICKLUNGSUMGEBUNG

Während man die Oberfläche selbst in SAPUI5 erstellt, werden die ei-
gentlichen OData-Services im Backend mit ABAP programmiert. Die
vorgegebenen Klassen lassen hier erweitern, in dem man die entspre-
chenden Methoden überschreibt. Im besten Fall kommen dafür die
Funktionsbausteine (FuBas) und Business Application Programming
Interfaces (BAPIs) zum Einsatz. Über das Open Data (OData) Protocol
und das SAP NetWeaver Gateway kommunizieren beide Ebenen mitei-
nander.

15
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Für die Programmierung des GUIs stehen zwei Entwicklungsumge-


bungen (IDE) zur Verfügung. Eine webbasierte (WebIDE) sowie SAPUI5
Plugins für Eclipse. Eclipse wird zur Entwicklung von Software ver-
schiedenster Art genutzt, insbesondere für Java als integrierte Entwick-
lungsumgebung. SAP stellt für Fiori die sogenannten „SAPUI5 Tools“
bereit, die als Plugins den Weg in die Eclipse Versionen Mars (4.5) oder
Luna (4.4) finden.

Bei WebIDE wird analog zu Web Dynpro immer das Model-View-Control-


ler-Architekturmuster angewandt. Hier stehen vier verschiedene Daten-
modelle zur Verfügung: OData als Backend-Repräsentation sowie JSON,
XML, Resource für den Client. OData ist ein serverseitiges Modell und
lädt nur die von der Benutzeroberfläche angeforderten Daten vom Ser-
ver. JSON, XML und Resource sind Client-bezogen, d.h. die Modelldaten
werden vollständig geladen und stehen auf dem Client zur Verfügung.
Operationen wie Sortieren und Filtern werden auf diesem ohne weitere
Serveranfragen ausgeführt.

Bei der App-Entwicklung in SAPUI5 können unterschiedliche Modelle für


verschiedene Bereiche der Anwendung definiert sowie auch einzelne
Controls einem Modell zugeordnet werden. Modelle lassen sich darüber
hinaus schachteln, z.B. ein für die Anwendung definiertes JSON-Modell
und ein OData-Modell für ein in der Anwendung enthaltenes Table Con-
trol. Eine Web-Anwendung sollte grundsätzlich mehrere Datenformate
unterstützen, also JSON, XML, Atom oder OData. Die Art und Weise, wie
die Datenbindung innerhalb der User Interface (UI) Controls definiert
und implementiert wird, sollte jedoch von diesen unabhängig sein. Es
ist auch möglich, eine benutzerdefinierte Modellimplementierung für
Datenquellen zu erstellen, die noch nicht durch das Framework abge-
deckt sind oder domänenspezifisch sind.

16
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Features von SAPUI5 für Eclipse:


• Code Completion
• Syntax Highlighting
• Deployment der App auf ein ABAP-Backend-System
• Quellcodeverwaltung über weiteres Plugin möglich

Features von SAP WebIDE:


• Syntax Highlighting
• Code Completion
• Templates um bspw. den Rumpf einer Master-Detail-App
generieren zu lassen
• Integrierter Git Client zur Quellcode Verwaltung
• Layout Editor zum Erstellen von Views mittels Drag & Drop
• Wizards zur Erweiterung von Standard Fiori Apps der SAP
• Deployment der App auf ein ABAP-Backend-System oder direkt
in die HANA Cloud Platform

Welche IDE verwendet werden sollte, hängt stark von der individuellen
Situation im Unternehmen ab. Um die in WebIDE entwickelten Apps in
das lokale SAP-Entwicklungssystem zu überführen, ist stets eine Ver-
bindung mittels SAP Cloud Connector notwendig. Zudem fallen hier
zusätzlich Lizenzkosten für den produktiven Einsatz an, was zunächst
für Eclipse spricht. Jedoch setzt SAP auf WebIDE zur Fiori UI-Entwick-
lung und entwickelt neue Features im Wesentlichen nur noch für diese
Umgebung. In diesem Zuge hat sich die Full Stack-Version der WebIDE
entwickelt, die weitere Möglichkeiten zur Verfügung stellt.

17
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Themes

Definiert wird das Erscheinungsbild mittels vorgefertigter Themes, die


im Kopf der Anwendung eingebunden werden. SAP-Anwender können
selbstdefinierte Themes für SAPUI5- und Unified-Rendering-Technolo-
gien anlegen. Die heute gebräuchlichsten Themes sind SAP Blue Crystal
Design und SAP Belize als dessen Nachfolger (Blue Chrystal ist ab Versi-
on 1.40 für SAPUI5-Anwendungen veraltet. Mit diesem Theme selbst er-
stellte Apps sollten daher nach Belize migriert werden). SAP Belize stellt
ruhige Farbtöne zur Verfügung und verdeutlicht Inhalte mittels sauberer
und konsistenter UI-Layouts in großer Klarheit. Mikro-Interaktionen und
Typografie wurden im Sinne eines intensiveren Benutzererlebnisses mit
einer Reihe von Details angereichert.

Weitere, heute aber kaum noch verwendete Themes sind Platinum (sap_
platinum), High Contrast Black (sap_hcb), Gold Reflection (sap_goldre-
flection).

3.6 MODEL VIEW CONTROL

Präsentationsschicht, Datenhaltung und Datenverarbeitung werden in


OpenUI5 mittels Model View Controller (MVC, englisch für Modell-Prä-
sentation-Steuerung) getrennt. Dabei handelt es sich um ein Archi-
tektur- oder Entwurfsmuster zur Unterteilung von Anwendungskom-
ponenten in drei eigenständige Module: Model (Datenhaltung), View
(Darstellung/Präsentation) und Controller (Datenverarbeitung). Die User
Interaction (also die Eingabe von Daten, das Klicken von Buttons) findet
dabei auf der Präsentationsschicht statt. Das Model enthält die Daten
bzw. Teile des aktuellen Zustands der Anwendung sowie ggf. auch die
Geschäftslogik.

18
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Es ist das zu beobachtende Subjekt und wird auch als Publisher (Veröf-
fentlicher) bezeichnet.

Views sind als Präsentationsschicht für die Darstellung der benötigten


Daten aus dem Modell und die Entgegennahme von Benutzerinteraktio-
nen zuständig. Sie „visualisieren“ Daten, die in Modellen der Anwendung
enthalten sind. Der Controller steuert die Anwendung, nimmt Eingaben
aus unterschiedlichen Quellen entgegen (Eingaben des Nutzers, Sens-
ordaten) und leitet sie an ein Modell weiter.

Das MVC-Konzept wurde 1979 erstmals beschrieben und gilt heute als
De-facto-Standard für den Grobentwurf komplexer Softwaresysteme.
Die Unterteilung vereinfacht spätere Änderungen oder Erweiterungen
und ermöglicht eine Wiederverwendbarkeit der einzelnen Komponen-
ten. So können Anwendungen mit demselben Modell erstellt und an-
schließend für verschiedene Umgebungen (Windows, Apple, Linux, Web)
zugänglich gemacht werden. Dafür müssten jeweils nur Controller und
View neu implementiert werden.
Views und Controller bilden oft eine 1:1-Beziehung. Es ist aber auch
möglich, Controller ohne User Interface zu verwenden, dann spricht
man von “Application Controller“. Andersherum lassen sich auch Views
ohne Controller erstellen. Technisch gesehen ist ein View ein OpenUI5
Control.

Modelle

Das OData-Modell ermöglicht die Bindung von Steuerelementen an


Daten aus OData-Diensten, und zwar Two-Way (Standard), One-Way
oder One-Time. Es ist ein serverseitiges Modell und lädt nur die von

19
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

der Benutzeroberfläche angeforderten Daten vom Server. Derzeit un-


terstützt das Modell nur die OData-Versionen V2 und V4, letztere mit
eingeschränktem Funktionsumfang.
Das JSON-Modell, das XML-Modell und das Ressourcenmodell sind cli-
entseitige Modelle, d.h. die Modelldaten werden vollständig geladen
und stehen auf dem Client zur Verfügung. Operationen wie Sortieren
und Filtern werden auf dem Client ohne weitere Serveranfragen aus-
geführt.

Das JSON-Modell kann verwendet werden, um Steuerelemente an Java-


Script-Objektdaten zu binden, die normalerweise im JSON-Format se-
rialisiert werden. Es ist ausgelegt auf kleine Datensätze, die vollständig
auf dem Client verfügbar sind und unterstützt Two-Way-, One-Way und
One-Time-Bindungsmodus (s.u. „Datenbindung“). Ebenfalls für kleine
Datensätze auf dem Client konzipiert ist das XML-Modell. Es enthält
keine Mechanismen für serverbasiertes Paging oder Laden von Deltas
und unterstützt wie die vorangegangenen alle drei Modi. Das Ressour-
cenmodell schließlich wurde entwickelt für die Verarbeitung von Daten
in Ressourcenbündeln, hauptsächlich für die Bereitstellung von Texten
in verschiedenen Sprachen. Da es hier nur um statische Inhalte geht,
wird nur der One-Time-Bindungsmodus unterstützt,

3.7 WAS SIND EIGENTLICH UI CONTROLS?

Ein UI Control ist ein visuelles Element auf dem Bildschirm (auch als
„Widget“ bezeichnet), über das der Anwender mit der dahinterliegen-
den Software interagiert. Beispiele sind Schaltflächen, Ankreuzfelder,
Links, Diagramme oder Fenster. Mehr als rein visuelle Elemente sind UI
Controls aber auch technische Bausteine mit vordefinierten Attributen,

20
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Methoden und Werten, die eine konsistente Visualisierung und Inter-


aktion ermöglichen.

Zur Verfügung gestellt werden UI Controls in einer Steuerungsbiblio-


thek (Control-Library). Aus dieser wählt der Anwendungsentwickler die
benötigten Controls sowie gegebenenfalls vorkonfigurierte Attribute
aus. Zum Beispiel könnte er ein Formular erstellen, bei dem ein Häk-
chen bereits in einem Ankreuzfeld vorhanden ist, anstatt eines leeren
Kästchens (der Standardeinstellung). Dies könnte den Benutzer dahin
führen, diese spezielle Option auszuwählen. Da das Kontrollkästchen
jedoch aktiviert ist, kann der Benutzer es immer noch deaktivieren. Die
Attribute „Checked“ und „Unchecked“ sind Beispiele für Attribute des
Checkbox-UI-Controls.

Die Arbeit mit der konsolidierten Steuerungsbibliothek erleichtert dem


Entwickler mit der Softwareerstellung einhergehenden Versionierungs-
prozess. Die Beziehungen zwischen den Steuerelementen werden darin
deutlich, so dass Designer und Entwickler die Benutzerfreundlichkeit auf
verschiedenen Ebenen besser gewährleisten können. So können etwa
Tastaturzugänglichkeit, Unterstützung für Bildschirmleseprogramme
und Farbverwendung einheitlich behandelt werden, was dem Anwender
ein einheitliches Erlebnis bietet. Auch die Rendering-Performance lässt
sich effizienter behandelt werden. Abhängigkeiten, die für die Designan-
passung für Kunden wichtig sind, können systematischer analysiert wer-
den. So rationalisieren UI-Control-Bibliotheken den Entwicklungspro-
zess, indem sie Designern und Entwicklern ein konsistentes Toolset für
ihre UI-Arbeit zur Verfügung stellen. Diese müssen die Steuerelemente
nicht jedes Mal neu erstellen, wenn sie eine Anwendung erstellen.

21
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

3.8 DATENBINDUNG

Unter Datenbindung versteht man die Kopplung zweier Daten- bzw.


Informationsquellen, sodass beide synchronisiert werden und Daten
automatisch zwischen ihnen weitergegeben werden. Alle Änderungen
in einer Quelle spiegeln sich dann in der anderen Datenquelle wider.
Für die Datenbindung benötigen werden ein Modell und eine Daten-
bindungsinstanz: Das Modell hält die Daten und stellt Methoden zur
Verfügung, um Daten zu setzen oder von einem Server abzurufen. Es
stellt auch eine Methode zur Verfügung, um Datenanbindungen an die
Daten zu erstellen. Wird die Methode aufgerufen, erzeugt das Modell
eine Datenbindungsinstanz, welche die Datenflussinformationen enthält
und ein Ereignis liefert, das bei jeder Änderung der gebundenen Daten
ausgelöst wird.
Im User Interface wird Datenbindung verwendet, um UI Controls an
das Modell zu binden, welches die Anwendungsdaten enthält. Dadurch
werden die Controls automatisch aktualisiert, sobald sich Anwendungs-
daten ändern. Datenbindung kommt auch dann zum Einsatz, wenn Än-
derungen in der Steuerung zu Aktualisierungen der zugrundeliegenden
Anwendungsdaten führen, z.B. wenn ein Benutzer Daten eingibt.

Der Standardbindungsmodus für Modellimplementierungen (sofern


nicht anders implementiert) ist Two-Way; die vom Modell unterstützten
Bindungsmodi sind Two-Way, One-Way und One-Time. Der Standard-
bindungsmodus kann von der Anwendung für jede Modellinstanz ge-
ändert werden. Eine Modellimplementierung sollte ihre unterstützten
Bindungsmodi spezifizieren und den Standardbindungsmodus entspre-
chend einstellen. Unterstützt z.B. das Modell nur One-Way-Bindung,
sollte dies auch der Standardmodus sein.

22
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Bindungsmodi

Der Bindungsmodus legt fest, wie die Datenquellen gebunden werden.


Die verschiedenen Modellimplementierungen erfordern spezifische Bin-
dungsmodi. Das Ressourcenmodell unterstützt z.B. nur einen einmali-
gen Datenfluss, d.h. von Modell zu View.

OpenUI5 stellt die folgenden Bindungsmodi zur Verfügung:

1. One-Way bedeutet eine Bindung von Modell zu View; Wertände


rungen im Modell aktualisieren alle entsprechenden Bindungen
und die Ansicht.
2. Two-Way ist die wechselseitige Anbindung zwischen Modell und
View. Wertänderungen in einer der beiden Komponenten
bewirken die Aktualisierung in der jeweils anderen.
3. One-Time bedeutet die einmalige Bindung von Modell zu Modell.

Mit der Elementbindung lassen sich Elemente an ein bestimmtes Objekt


in den Modelldaten binden. Dadurch wird ein verbindlicher Kontext
erzeugt und eine relative Bindung innerhalb des Controls und aller sei-
ner Derivate ermöglicht. Dies ist insbesondere hilfreich in Master-De-
tail-Szenarien.

Aggregationsbindungen werden verwendet, um untergeordnete Steu-


erelemente anhand von Modelldaten automatisch zu erstellen. Mit
Property Bindings können Eigenschaften eines Controls automatisch
initialisiert und auf Basis der Daten des Modells aktualisiert werden.

23
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

3.9 FRAGMENTE

Fragmente sind leichtgewichtige Teile (Teilbäume) des UI. Sie lassen


sich wiederverwenden und sind ähnlich definiert wie Views, enthalten
jedoch keinen Controller oder anderen Verhaltenscode.

Fragmente, die in mehreren Views verwendet werden sollen, sind nicht


einfach zu definieren. Sie müssen entweder als neue Controls oder als
Views angelegt werden. Das Anlegen als neue Controls führt zu einem
Entwicklungs-Overhead, auf der anderen Seite führt das Anlegen als
separate Views zu einem Laufzeit-Overhead. Im letzteren Fall hätten sie
einen separaten, und nicht den gleichen Controller wie der View. Auch
Ansichten und Popup-Steuerelemente (Dialoge) passen nicht gut zusam-
men. Der Dialoginhalt kann als View definiert werden, die Dialogsteu-
erung selbst aber muss immer in das Programm geschrieben werden.

Ein wichtiges Merkmal von Fragmenten ist ihre Unabhängigkeit vom


Model-View-Controller-Konzept. Sie können also ohne Einsatz von MVC
verwendet werden, jedoch Views und Controllern nutzen sowie integ-
rieren, sofern sie gemeinsam mit diesen verwendet werden.

Ähnlich wie „DocumentFragments“ in HTML hat das Fragment selbst


keine HTML-Darstellung, wenn es in den UI- Baum eingefügt wird. Statt-
dessen wird sein Inhalt eingefügt. Das bedeutet, dass Fragmente nicht
wie Controls agieren, sondern eher wie eine „Fabrik“, welche die ent-
haltenen Controls erstellt. Sie unterstützen Wiederverwendung und
Modularisierung ohne zusätzlichen Overhead.

24
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

OpenUI5 stellt verschiedene Arten von Fragmenten zur Verfügung:

• XML-Fragmente
• HTML-Fragmente
• JS-Fragmente

Weitere Fragmenttypen können implementiert und eingesteckt werden.

Die Definition eines Fragments ist vergleichbar mit der Definition von
Ansichten innerhalb einer separaten Datei. Die Fragmente enden ein-
fach mit *.fragment statt mit *.view. Für den Speicherort der Dateien
gelten die gleichen Regeln.

3.10 AUTOMATISIERTES TESTEN

Mit Unit- und Integrationstests sowie dem Mock Server bietet OpenUI5
verschiedene Testoptionen. Vor der Implementierung des ersten Tests
sollte man darüber nachdenken, wie sich die verschiedenen Aspekte
der Anwendung testen lassen. Mock-Server ist ein Mocking-Framework
für HTTP und HTTPS. Es beschreibt zunächst nur die Eigenschaft eines
Servers, so genannte Mock-Daten (also solche, die nur für Testzwecke
verwendet werden) zu liefern. Somit kann auch gegen den Service ent-
wickelt werden, wenn dieser unvollständig oder instabil ist. Integrati-
onstests werden dadurch vereinfacht, Entwicklungsteams entkoppelt.

In OpenUI5 imitiert der Mock-Server OData-Backend-Aufrufe. Er si-


muliert den OData-Provider und ist vollständig clientbasiert, d.h. es
ist keine Netzwerkverbindung zu einem entfernten Host erforderlich.

25
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

HTTP-Aufrufe an den Server fängt der Mock-Server ab und liefert eine


gefälschte Ausgabe an den Client. All dies ist transparent für die Daten-
bindung und die Verwendung des OData-Modells und vermittelt den
Eindruck eines „echten“ Servers. Am OData-Modell sind dabei keine
Änderungen erforderlich.

Der Mock-Server stellt sowohl Mock-Dienste als auch -Daten zur Verfü-
gung. Er unterstützt zufällig generierte Daten, die auf den Service-Me-
tadaten basieren, sowie Mock-Daten, die in JSON-Dateien bereitgestellt
werden.

4 OPEN DATA PROTOCOL


(ODATA)
OData ist ein auf HTTP basierendes Open-Source-Protokoll, das für den
strukturierten und technologieunabhängigen Datenaustausch zwischen
kompatiblen Softwaresystemen über das Internet verwendet wird. Es
ermöglicht die Erstellung von Representational State Transfer (REST)-ba-
sierten Datendiensten. Mit diesen können Ressourcen durch Web –Cli-
ents veröffentlicht und bearbeitet werden, die über Uniform Resource
Identifiers (URI) identifiziert und in einem Datenmodell definiert sind.
Dabei werden HTTP-Nachrichten verwendet. OData lässt sich auch in
Cloud-Dienste einbinden und stellt damit eine einheitliche Semantik für
den Datenaustausch in der Client-Server-Kommunikation zur Verfügung.

Im OData-Protokoll werden die Ressourcen in zwei sog. Payload-Forma-


ten ausgesetzt. Als Payload bezeichnet man die innerhalb eines Paketes

26
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

oder einer anderen Einheit an den Nutzer übertragenen Nutzdaten.


Woraus diese letztlich bestehen, ist grundsätzlich abhängig von der
Betrachtung bzw. dem Kontext des jeweiligen Protokolls. Nicht darin
enthalten sind der Overhead und die für die Übertragung notwendigen
Metadaten, es sei denn, die Kommunikationsschicht erfordert einen be-
stimmten Teil der Overhead-Daten (Quelle: http://www.searchsecurity.
de/definition/Payload).

Payload-Formate bei OData sind zum einen das auf XML basierende
Atom und zum anderen JSON. Atom bezeichnet eine Kombination aus
zwei Protokollen: Atom Syndication und das Atom-Publishing-Protokoll.
Ersteres ist ein XML-Dialekt, während das Atom-Publishing-Protokoll ein
einfaches HTTP-basiertes Protokoll beschreibt. JSON ist die Abkürzung
für JavaScript Object Notation und ist selbstbeschreibend, einfach in
der Handhabung und vollständig sprachenunabhängig.

Die Nutzung des Protokolls bietet neben der Möglichkeit des struktu-
rierten sowie technologieunabhängigen Datenaustauschs weitere Vor-
teile. Dazu gehört die Option, konsistente und plattformunabhängige
Webschnittstellen zu entwickeln sowie zur Verfügung zu stellen. Zudem
ist es möglich, den entwickelten Service kombiniert mit Metadaten aus-
zusetzen. Hinzu kommt die Unabhängigkeit von Programmiersprachen,
womit nur notwendige Informationen beim Abruf geladen werden.

Was ist REST bzw. ein RESTful Service?

Representational State Transfer (REST) ist ein Programmierparadigma


für Webservices und andere verteilte Systeme. Der Name drückt den
Übergang vom aktuellen zum nächsten Zustand (state) einer Applikation

27
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

aus. Der Übergang besteht im Transfer der Daten, die den nächsten Zu-
stand repräsentieren. Von anderen Architekturstilen unterscheidet REST
sich vor allem in der Forderung nach einer einheitlichen Schnittstelle.
Damit stellt es die Anforderungen des modernen Webs bestmöglich dar.

REST zielt schwerpunktmäßig auf die Maschine-zu-Maschine-Kommu-


nikation ab und stellt dabei eine einfache Alternative zu ähnlichen Ver-
fahren wie SOAP, WSDL oder RPC dar. Anders als bei verwandten Archi-
tekturen kodiert REST keine Methodeninformation in den URI (da dieser
den Ort und Namen der Ressource angibt, nicht aber die Funktionalität,
die der Web-Dienst zu der Ressource anbietet).
Hier erweist es sich als Vorteil, dass im Web bereits ein Großteil der für
REST nötigen Infrastruktur (z. B. Web- und Application-Server, HTTP-fä-
hige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhan-
den ist.

Viele Web-Dienste sind außerdem bereits REST-konform, z.B. jeder


Dienst, der lediglich unveränderte HTTP-basierte Seiteninhalte anbietet.
Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch oft nicht.
So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Infor-
mationen mit sowohl unterschiedlichem Format als auch Inhalt an, die
nur schwer automatisch verarbeitet werden können. Bliebe das Format
unverändert, so wäre eine wichtige REST-Eigenschaft erfüllt. Ein typi-
sches Beispiel für REST-konforme Webseiten ist Twitter. Man erreicht
sowohl sein eigenes Profil als auch den jeweiligen Status des Feeds über
einen spezifischen URI.

28
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

4.1 SERVICE-IMPLEMENTIERUNG

Ein OData-Service stellt vier Basis-Datenbankoperationen zur Verfügung,


die unter dem Akronym CRUD zusammengefasst werden.

• Create (Anlegen des Datensatzes)


• Read oder Retrieve, (Lesen des Datensatzes)
• Update (Aktualisieren d. D.)
• Delete (Löschen d.D.)

CRUD-Operationen werden oft mittels einer Persistenz-Schicht umge-


setzt. Diese transferiert die relationale Repräsentation der einzelnen
Informationen auf eine objektorientierte Ebene. Von einem CRUD-Fra-
mework wird gesprochen, wenn die einzelnen Datenobjekte zusätzlich
in einer grafischen Benutzeroberfläche visualisiert werden, in der Regel
einem einfachen HTML-Interface. Die Objekte können dann durch eine
CRUD-Operation manipuliert werden. Das CRUD-Framework berücksich-
tigt typischerweise einzelne Transaktionsschritte. Dadurch lassen sich
Daten nur dann speichern und die Update-Operation wird ausgeführt,
wenn im GUI der Speichern- bzw. Weiter-Button gedrückt wird.

Jede CRUD-Operation stellt einen atomaren Vorgang dar, d.h. einen Ver-
bund von Einzeloperationen, der als logische Einheit betrachtet werden
kann und nur als Ganzes fehlschlägt oder erfolgreich abläuft. Dies ist in
diesem Zusammenhang wichtig, da moderne Software-Anwendungen
oft als Mehrbenutzersystem realisiert werden. Ein CRUD-Framework
erlaubt Lesen und Schreiben eines Datensatzes auch dann, wenn beide
Operationen zeitlich stark versetzt stattfinden. Für andere Personen
hingegen ist er gesperrt, d.h. sie können ihn nicht zur WWselben Zeit
auslesen. (Quelle: https://www.wikiwand.com/de/CRUD)

29
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

4.2 ERSTELLEN EINES ODATA-SERVICES

Für die Erstellung eines OData-Services muss dieser im ersten Schritt


definiert werden. Ein nützliches Tool dafür ist das Plugin OData Modeler
für die Eclipse IDE. Mit diesem kann der Service schneller und intuitiver
erstellt werden, als dies im SAP GUI möglich wäre. Im nächsten Schritt
wird der Service als XML-Datei exportiert, in das SAP-System importiert
und dort als Service registriert.

Nach Installation des OData Modelers kann mit der Erstellung des
OData-Modells begonnen werden. Es besteht aus Entitäten, die für
gleichartige Objekte stehen, welche auch zu Mengen (bzw. Sets) zu-
sammengefasst werden können. OData kann nun eine einzelne Entität,
die komplette Collection oder eine gefilterte Collection zurückgeben.

Nach dem Import des Modells nach SAP muss es mit Logik befüllt wer-
den. Dazu werden Laufzeitartefakte generiert. Das sind ABAP-OO-Klas-
sen, welche für die Geschäftslogik sorgen, wenn der OData Service ge-
nutzt wird. Diese Klassen können automatisch generiert, müssen aber
dann fertig implementiert werden. Der letzte Schritt ist die Registrierung
des Service am Gateway, anschließend kann er im Browser aufgerufen
werden.

Entity Data Model

Das Entity Data Model (EDM) umfasst eine Reihe von Konzepten, die eine
Datenstruktur unabhängig von der gespeicherten Form beschreiben. Es
löst damit die Herausforderungen, die sich aus dem Speichern von Da-
ten in vielen Formen ergeben. Entwickelt wurde das EDM von Microsoft;

30
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

es ist aus dem 1976 von Peter Chen beschriebenen Entitätsbeziehungs-


modell ausgeliehen, baut aber auch auf dem Entity Relationship (ER-)
Model auf und erweitert dessen herkömmliche Verwendung.

Unternehmen speichern ihre Daten in der Regel sowohl in relationalen


Datenbanken als auch in Text- und XML-Dateien, Arbeitsblättern oder
Berichten. Daraus erwachsen besondere Anforderungen an die Daten-
modellierung, den Anwendungsentwurf und Datenzugriff. Bei einer
relationalen Datenstruktur sind Datenzugriff, Speicherung und Skalier-
barkeit sehr effizient, jedoch wird das Schreiben von effizientem und
verwaltbarem Code schwieriger. Umgekehrt bei einer objektorientierten
Struktur: Hier gehen Effizienz beim Schreiben des Codes zu Lasten von
Datenzugriff, Speicherung und Skalierbarkeit.

Das Ziel beim Entwerfen datenorientierter Anwendungen besteht also


darin, effizienten und verwaltbaren Code zu schreiben, ohne Abstriche
bei Datenzugriff, Speicherung und Skalierbarkeit machen zu müssen.
Auch wenn dabei eine zufriedenstellende Balance erzielt wurde, erge-
ben sich neue Herausforderungen, sobald Daten zwischen Formen ver-
schoben werden. Hier greift das Entity Data Model in dem Sinne, dass
die Datenstruktur in Bezug auf Entitäten und Beziehungen beschrieben
wird, die losgelöst von einem Speicherschema sind. Die gespeicherte
Datenform ist damit unabhängig von Anwendungsentwurf und Entwick-
lung. Da Entitäten und Beziehungen die Datenstruktur beschreiben, wie
sie in einer Anwendung verwendet wird – und nicht der gespeicherten
Form – können sie mit der Anwendung weiterentwickelt werden.

31
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

4.3 API MANAGEMENT MIT POSTMAN

Postman ist eine funktionsmächtige GUI-Plattform zur einfachen und


schnellen API-Entwicklung. Als Toolset ermöglicht Postman nahtlose
Workflows bei der Zusammenarbeit und beinhaltet alle für den API-Ent-
wickler notwendigen Features: Entwurf von API Requests, Testmanage-
ment und -automation, komplette API-Dokumentation (mit beispielhaf-
ten Requests, Antworten und ausführlichen Beschreibungen), Teilen,
Verwalten verschiedener Services, Mock Services (einfaches Erstellen
von Dummys, Testen, bevor Frontend oder Backend fertig sind), etc.

Zum Erreichen von Konsistenz, bestmöglicher Performance und User


Experience basieren Postman-Apps auf einer einheitlichen Schicht. Post-
man ist als kostenfreie App für Mac, Windows und Linux verfügbar und
lässt sich wahlweise als Browser-Anwendung oder Stand-Alone-Tool
einsetzen.

5 EXKURS FIORI MENTOR APP


Die Fiori Mentor App stellt eine interaktive Dokumentation für das Soft-
ware Developer Kit für iOS auf der SAP Cloud Platform zur Verfügung.
Damit unterstützt und vereinfacht sie die Entwicklung von SAP Fiori
Apps für iPad/iPhone. Entwickler können sich Live-Vorschauen aller
UI-Komponenten mit verschiedenen voreingestellten SAP-Fiori-Stilen
anzeigen lassen und Parameter ändern, um den Effekt sofort zu kon-
trollieren. Direkt nach Anpassen einer Komponente wird das fertige
Code-Schnipsel auf dem iPad/iPhone angezeigt, kopiert und über das
Universal Clipboard auf dem Mac in xcode eingefügt.

32
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

Der Inspiration dienen Demo-Apps wie der SAP Asset Manager (nutzt
iBeacon, Geolocation, Foto, Fingerprint, FaceTime) bis hin zu SAP Co-
Pilot, dem virtuellen Assistenten von SAP. Sie zeigen auch an, welche
Komponenten für ihre Erstellung eingesetzt wurden. Für den Zugriff auf
einige Teile der referenzierten Dokumentation ist ein Account der SAP
Cloud Platform erforderlich.

33
APP-ENTWICKLUNG MIT SAPUI5 UND ODATA

MISSION MOBILE –
DIE EXPERTEN FÜR MOBILE
APPS IM SAP UMFELD
Wir gehören zu den Top Beratungsunternehmen für mobile
Lösungen im SAP-Umfeld im deutschsprachigen Raum.

Unsere Entwickler und Consultants bringen Ihren Wunschprozess


mit der passenden Technologie auf Ihr mobiles Endgerät.
Starten Sie mit uns sicher in die mobile Zukunft. Egal, ob Sie
wissen möchten, was sich hinter SAP Fiori verbirgt oder Sie Ihre mo-
bile Logistik optimieren möchte: Wir helfen Ihnen gerne
weiter.

Produkte im Überblick

Unsere Expertise geben wir regelmäßig auch in Seminaren und Work-


shops weiter

Schulungen im Überblick

Kontaktieren Sie uns

34