3.5 Möglichkeiten, Ihre SAP Fiori-Anwendung offline zu betreiben

Mithilfe von Fiori Apps können Sie einfach mit mobilen Endgeräten auf Ihr SAP-System zugreifen. Aber was können Sie tun, wenn Sie offline sind oder die Verbindung instabil ist? In diesem Artikel zeige ich Ihnen verschiedene Möglichkeiten, wie Sie SAP UI5 Anwendungen offline zur Verfügung stellen. Vielleicht fragen Sie sich, warum eine Webapplikation überhaupt offline funktionieren soll. Die Antwort ist einfach: Es gibt viele Situationen, in denen die Netzwerkverbindung schlecht ist oder vorübergehend ganz abbricht, zum Beispiel auf Reisen in Funklöchern, in abgelegenen Büro- und Fabrikräumen oder in Lagerhallen.

Die meisten Fiori-Anwendungen sind im Grunde nichts anderes als eine Fernsteuerung für SAP-Backend-Funktionen und alle Rechenoperationen finden auf dem Server statt. Verbindungsabbrüche im Midstream führen zum Verlust sämtlicher Backenend-Funktionen und schneiden den Benutzer von allen Funktionen ab. Um dies zu vermeiden muss gewährleistet sein, dass der Anwender zeitweise offline arbeiten kann, ohne Einschränkungen in der Bedienung hinnehmen zu müssen. Technisch gesehen bringt dies drei wesentliche Herausforderungen mit sich:

  1. Die App muss offline starten und neustarten können: daher müssen alle UI-Elemente wie etwa Javascript und Bilder auch ohne Verbindung zum Server erreichbar sein.
  2. Erforderliche Daten wie zum Beispiel der aktuelle Arbeitsvorrat müssen offline zugänglich sein.
  3. Änderungen der Daten und Aktionsaufrufe, die normalerweise sofort an den Server gesendet werden, müssen auf dem Client verarbeitet und, nach Widerherstellung der Verbindung, an den Server gesendet werden.

Kurz gesagt, muss eine Kopie der App-Struktur und eine Teilmenge der Daten auf dem Client vorgehalten und mit dem Server synchronisiert werden. Und zwar immer dann, wenn es durch eine stabile Verbindung zum Backend möglich ist. Dies zu realisieren ist alles andere als trivial. Webbrowser stellen normalerweise nur das dar, was ein Server übermittelt. Für die Speicherung der übermittelten Inhalte für längere Zeit hingegen ist der Browser nicht ausgelegt. Glücklicherweise gibt es Möglichkeiten, diese Schwierigkeit zu überwinden.

Überblick

Die folgende Funktionsmatrix zeigt alle Möglichkeiten im direkten Vergleich.

Funktion SAP offline oData + Cordova Neptune UXP Progressive Web Apps AppCache
Installation auf Gerät erforderlich Ja Nein Nein Nein
Dediziertes App-Icon Ja Ja Ja Ja
App kann offline gestartet werden Ja Nein Ja Ja
Datenteilmenge kann offline gehalten werden Ja (Replication) Ja (Replication) Ja (Cache) Ja (Replication)
Daten können offline geändert und später synchronisiert werden. Ja (Sync.) Ja (Sync.) Ja (Puffer oder Sync.) Ja (Sync.)
Sync-Tools für UI5 verfügbar im Standard Ja Ja Nein Nein
Voraussetzungen SAP Cloud Platform oder
SAP Mobile Platform
Neptune UX Plattform  –  –
Funktioniert auf Fiori Launchpad Nein Nein Nur Online *** Nur Online ***
Funktioniert als BSP auf NetWeaver Nein Nein Ja Ja
Mobile Unterstützung Android, iOS Android, iOS, Windows Android, iOS**, Windows 10 Veraltet
Desktop-Unterstützung  – Chrome, Firefox, Safari
Edge, IE11
Chrome, Firefox, Safari**,
Edge
Veraltet
Hintergrund-Synchronisation Ja Ja (wenn im Browser geöffnet) Ja Nein
Client-seitiges Speicherlimit * freier Gerätspeicher
(max. 2 TB)
5-50 MB 0,2-1%  des Gerätespeichers 5 MB

* Das Speicherlimit hängt stark vom Browser und dem Betriebssystem ab. Die angegebenen Zahlen sind nur typische Orientierungswerte.

** Safari unterstützt derzeit (06.2018) nur Basis-APIs für PWA – insbesondere die Background Sync API wird noch nicht unterstützt.

*** Ein PWA kann vom Fiori Launchpad aus gestartet werden, funktioniert aber nur als normale Webapplikation. Stand Juli 2018 gibt es keine Möglichkeit mehr, einen ServiceWorker zu registrieren.

SAP offline oData

SAP selbst empfiehlt, für die Bereitstellung von Offline-Funktionalitäten auf native oder hybride Apps zurückzugreifen. Für die temporäre Offline-Bereitstellung benötigter Informationen und Daten wäre eine Hybrid-App – also eine Web-App, die in einem speziellen Container statt in einem normalen Browser läuft – eine gute Idee.

Der Container selbst ist hierbei eine native mobile Anwendung und bietet Zugriff etwa auf den Gerätespeicher und die Hardwaretreiber. Eine solche hybride Anwendung verhält sich genau wie eine native Anwendung, mit Ausnahme der Benutzeroberfläche und der Logik, die auf HTML und JavaScript basieren. Hybride Anwendungen müssen hierbei wie herkömmliche Anwendungen installiert und aktualisiert werden.

SAP Offline oData

SAP stellt verschiedene Werkzeuge zur Verfügung, um hybride Anwendungen innerhalb der SAP Cloud Platform oder der SAP Mobile Platform zu erstellen. Beide verwenden als Container Apache Cordova und eine Reihe von SAP-Plugins namens „Kapsel Framework“. Die Offline-Unterstützung erfolgt in Form einer Middleware namens „Offline OData“. Diese Middleware liest eine Teilmenge der Serverdaten aus einem regulären OData-Dienst und repliziert sie auf angeschlossene mobile Geräte. Die mobile App funktioniert dann nur mit diesem Datenreplikat, das über ein Kapsel-Plugin wieder mit der Middleware synchronisiert wird. Die Middleware wiederum synchronisiert sich weiter mit der ursprünglichen Datenquelle. Die Synchronisation zwischen App und Middleware erfolgt nicht automatisch. SAP stellt Schnittstellen zur Verfügung, die allerdings manuell bedient werden müssen.

Unterm Strich kann eine UI5-Hybridanwendung vollständig offline arbeiten, sobald sie ihre Datenuntermenge erhalten hat: Das JavaScript und alle Assets sind im Cordova-Container verpackt und die Daten werden über Offline OData verteilt und synchronisiert. Voraussetzung für diesen Ansatz ist die Bindung an die SAP Cloud Platform oder die SAP Mobile Platform. Im Gegensatz zu herkömmlichen Fiori-Applikationen müssen Hybrid-Applikationen explizit auf jedem Gerät installiert und aktualisiert werden. In diesem Kontext ist es zudem wichtig zu verstehen, dass solche Apps immer mit ihrem Datenreplikat arbeiten, zumindest für den OData-Endpunkt, der offline gemacht wurde – auch wenn dieses unter Umständen gerade online ist. Zusätzlich kann jeder Schritt in der Synchronisation Fehler oder Konflikte hervorrufen, die behoben werden müssen (mehr dazu im Absatz Konflikt- und Fehlerbehebung).

Die Entscheidung, ob Offline OData verwendet werden soll oder nicht, muss aufgrund erheblicher Auswirkungen auf den Programmiercode frühzeitig im Entwicklungsprozess getroffen werden.

Neptun UX-Plattform

Die Neptune User Experience Platform ist eine Low-Code-Plattform von Drittanbietern für die Erstellung und den Betrieb von SAP UI5-Anwendungen. Herzstück ist ein JavaScript-Code-Generator mit einer tabellarischen Benutzeroberfläche mit Baumstruktur und den meisten Codierungen in ABAP. Darüber hinaus bietet es verschiedene Tools entlang des gesamten Lebenszyklus einer App. Neptune Apps arbeiten mit einem eigenen Backend, das in SAP integriert ist, aber über ein separates Launchpad verfügt.

Neptune UX Platform

Unter anderem gibt es die Möglichkeit, beliebige Daten für die Offline-Nutzung zwischenzuspeichern. Die Idee ist ähnlich wie bei SAP Offline OData. Sie haben die Möglichkeit, eine Teilmenge Ihrer OData-Entitäten in einer lokalen Datenbank innerhalb des Clients (LocalStorage oder WebSQL) zu speichern. Diese lokalen Daten werden automatisch aktualisiert: Alle Änderungen werden lokal vorgenommen und mit der Neptune UX-Plattform und von dort aus mit dem SAP-Backend synchronisiert.

Die Aktivierung der Offline-Unterstützung für eine Neptune-Anwendung ist denkbar einfach. Durch eine weitere Einstellung für einen OData-Dienst, bei der Sie wählen können, welchen Browserspeicher Sie verwenden möchten, wird die Offline-Unterstützung aktiviert. Ebenfalls an Bord ist eine JavaScript-API für den benutzerdefinierten Zugriff auf Offline-Daten. In realen Szenarien scheint der Einfluss der Offline-Unterstützung auf den App-Code geringer zu sein als bei Offline OData. Neptune Apps funktionieren übrigens auch auf Desktop-Browsern offline.

Neptune bietet allerdings keine Möglichkeit, die App-Struktur offline verfügbar zu machen. Das hat zur Folge, dass Ihre Daten offline nur auf dem aktuellen Stand sind, solange Sie die Seite im mobilen Browser nicht schließen oder neu laden. Diese Schwäche können Sie umgehen, indem Sie die Neptune Apps in Cordova Hybrid-Apps einbetten und verwenden.

Die Kapazitäten der Client-Speicheroptionen sind recht begrenzt: LocalStorage hat in den meisten Browsern ein Limit von 5 MB. WebSQL bietet zwar bis zu 50 MB, wird aber von Browsern schlecht unterstützt und als mangelhaft eingestuft. Sie können den Speicher durch die Verwendung von Cordova-Hybridanwendungen erhöhen.

Progressive Web Apps

Progressive Web Apps (PWA) nutzen die neuesten Browser-Technologien, um ein natives Erlebnis zu bieten – insbesondere dadurch, dass Web-Apps vollständig offline starten und arbeiten können. Die Hauptidee dahinter ist, Serveranfragen zwischenzuspeichern und bei Bedarf aus dem Cache zu bedienen. Für dieses Caching im Browser ist der sogenannte „Service Worker“ zuständig. Er erlaubt, alle HTML und JavaScripts und auch einige Daten vorab zu laden und die App ohne explizite Installation offline laufen zu lassen.

Progressive Web Apps with UI5

Aktuelle Versionen von SAP UI5 (ab 1.52) unterstützen ServiceWorker und die Browser-Cache-API. Der App-Entwickler muss einen ServiceWorker initialisieren und festlegen, welche Ressourcen zwischengespeichert werden sollen. Während HTML und JavaScript über die Cache-API nahezu automatisch auf dem Client gespeichert werden können, sollten die Daten in der Browser-Storage-Engine IndexedDB explizit aus dem Anwendungscode heraus gespeichert werden.

Der Unterschied zu Offline OData und Neptune besteht darin, dass die Offline-Daten nicht zwingend eine exakte Kopie einer OData-Sammlung auf dem Server sein müssen, die im Hintergrund synchronisiert wird. Der Entwickler kann frei wählen, ob die App immer mit den Offline-Daten arbeitet oder sie nur als Fallback nutzt, wenn keine Verbindung vorhanden ist. Es ist sogar möglich, verschiedene Ansätze für unterschiedliche Anforderungen zu wählen. Das bringt Flexibilität, erfordert aber auch ein sorgfältigeres Applikationsdesign.

Der Hauptvorteil von Progressive Web Apps ist die einfache Architektur auf Client- und Serverseite. Container und Middleware sind nicht erforderlich, und wie klassische Webanwendung bedürfen sie keinerlei Installationen, weder auf dem Client noch auf dem Server.

Allerdings gibt es keine vorgefertigten Werkzeuge für SAP UI5, so dass die gesamte Datensynchronisation von Grund auf neu programmiert werden muss. Außerdem unterstützen nicht alle Browser die PWA-Funktionen vollständig. Mit dem PWA-Checker lässt sich jeder Zielbrowser prüfen – öffnen Sie diesen einfach im Browser jedes Geräts, das Sie verwenden möchten.

AppCache (Manifest-Cache)

Viele ältere UI5-Tutorials empfehlen die Verwendung von HTML5 Application Cache, auch bekannt als Cache Manifest. Diese Technologie ist jedoch veraltet und wird nach und nach aus den Browsern entfernt. Im Jahr 2016 wurde sie vollständig durch den ServiceWorker ersetzt (siehe oben).

Der AppCache erlaubte es dem Browser, bestimmte Ressourcen für die Offline-Nutzung zwischenzuspeichern, indem ein spezielles Cache-Manifest im HTML verknüpft wurde. Diese Manifestdatei zählt alle Ressourcen auf, die zwischengespeichert und ignoriert werden sollen. Dieser Ansatz funktionierte jedoch bei größeren Anwendungen mit vielen Dateien nicht, da er nur eine Grundkonfiguration erlaubt war.

Konflikt- und Fehlerbehandlung

Die Behandlung von Konflikten und Serverfehlern ist bei einer zeitlich versetzten Synchronisation viel schwieriger als bei einer sofortigen Serverinteraktion. So kann beispielsweise ein Objekt auf dem Server geändert oder sogar gelöscht werden, während es offline noch verwendet wird. Speichert der Anwender Änderungen am Objekt offline ab, wird keine Fehlermeldung ausgelöst, da kein Abgleich mit den Daten auf dem Server stattfindet. So geht der Benutzer  davon aus, dass alles richtig gespeichert ist, obwohl die Synchronisation der Daten scheitern wird. Ein ähnliches Problem tritt auf, wenn komplexe Plausibilitätsprüfungen an Business-Objekten auf dem Server, jedoch nicht auf dem Endgerät durchgeführt werden, da nicht alle Logiken auf dem Client vorgehalten werden können.

Keiner der hier vorgestellten Offline-Ansätze bietet eine zufriedenstellende Lösung für die Behandlung von Hintergrundfehlern. Es ist Aufgabe des Entwicklers, eine Art Fehlerprotokoll oder eine andere Visualisierung zu erstellen und dem Anwender Möglichkeiten zum Umgang mit Konflikten zu bieten. In jedem Fall ist es wichtig, dies im Auge zu behalten, da es erhebliche Auswirkungen auf die Entwicklungskosten haben kann.

 

Hinterlassen Sie einen Kommentar

Nach oben