Die Zeiten der Pandemie zeigen, dass sich  mehr und mehr Tätigkeiten ins heimische Büro verlagern. Doch nicht erst seitdem dieser zusätzliche Datenverkehr die Infrastruktur verstärkt belastet, besteht die Anforderung, auch in WLAN- und mobilfunkfreien Bereichen, bestimmte Funktionen einer Anwendung verfügbar zu halten. In diesem zweiteiligen Expert-Blogbeitrag wird gezeigt, wie man die lokale IndexedDB dafür verwendet, App-Daten zu speichern. Das SAP oData v2 Model wird erweitert, sodass eine fehlgeschlagene Kommunikation mit dem SAP-Backend automatisch erkannt wird. Endpoint, HTTP-Verb und Payload werden in der IndexedDB zwischengespeichert und erneut abgeschickt, sobald die Anwendung wieder über eine Internetverbindung verfügt und somit eine Offline-Verwendung ermöglicht.

Inhalt Expertblog Teil 1/2

  1. Grundlagen
  2. Erstellung der Modelklassen
  3. Daten lesen: Online / Offline

1. Grundlagen & Definitionen

Was ist die IndexedDB?

Die IndexedDB ist eine Javascript basierte Datenbank. Sie erlaubt das lokale Speichern von Daten und Dateien. Die Daten werden, entsprechend der Same-Origin-Policy pro Host/Port, strukturiert und abgelegt. Hier werden keine fixen Spalten verwendet, sondern stattdessen Objekte mit Schlüssel abgelegt.

Scope

Ziel ist eine UI5-Anwendung, die eine einfache Liste anzeigt. Die Liste erlaubt das Hinzufügen und Löschen von Einträgen bei verfügbarem SAP-Backend-Server sowie fehlender Verbindung. Die Liste bietet außerdem eine Synchronisierungsfunktion, die alle Daten aus der lokalen IndexedDB an das SAP-System überträgt. In der Tabelle werden die Einträge aus dem SAP-Backend angezeigt. Ebenso die zu speichernden Einträge als auch die vorhandenen Einträge in der IndexedDB. Für den Nutzer funktioniert die Anwendung, unabhängig vom Netzwerkzustand, immer gleich.

IndexDB-Liste

OData Service

Der zugehörige OData Service hat nur die vier Felder, die in der Tabelle angezeigt werden. Er erlaubt die Query, „Create-“ und „Delete“-Funktionen.

Odata Service

JS-Klassen oData und IndexedDb

In der UI5-Anwendung werden neue Klassen für das oData Model sowie die IndexedDb erstellt.
Für die oData.js wird das sap/ui/model/odata/v2/ODataModel erweitert.
Für die IndexedDb.js wird das sap/ui/model/json/JSONModel verwendet.
Beide Klassen werden später aus der Component.js heraus instanziiert.

OdataJs Model

Fehlgeschlagene Calls an das SAP-Backend sollen direkt im OData Model abgefangen werden. Dafür muss das Standard SAP Odatamodel erweitert werden. Die benötigten Standard CRUD Methoden „Create“, „Read“ und „Remove“ werden dafür erweitert. In den Success- und Errorcallbacks werden eigene Methoden aufgerufen, die die Informationen an die IndexedDB weiterleiten.

oData.js

Copy to Clipboard

2.Erstellung der Modelklassen

Für den Zugriff auf die Funktionen der IndexedDB wird global ein JSON Model angelegt. Im Constructor wird die Datenbank geöffnet. Ist bereits eine geöffnete Instanz der IndexedDB vorhanden, wird die aktuelle Version global abgelegt.
Über das erweiterte oData Model werden die Metadaten aus dem SAP-Backend geladen. Analog wird ein JSON „Table Model“ angelegt. Über dieses wird das Laden und Speichern von Daten gesteuert.

Anlegen JSON Table Model Diagramm

IndexedDb.js

Copy to Clipboard

Initialisierung

Um auf die erweiterte ODatamodel-Klasse zugreifen zu können, wird die Model-Instanziierung aus der manifest.json entfernt …

Copy to Clipboard

… und in die Component.js / models.js verlagert

Copy to Clipboard

models.js:

Copy to Clipboard

3.Daten lesen: Online / Offline

Das Lesen der Daten erfolgt gradlinig über Table- und Odata-Model. Zusätzlich wird in der „load“-Methode des TableModels geprüft, ob unter dem gleichen Endpunkt auch eine Tabelle in der IndexedDB existiert. Ist dies der Fall, wird diese zusätzlich ausgelesen, um die Daten aus beiden Quellen anzeigen zu können.

Der Prozess, der über das Lesen der „Table1Set“ Entität angestoßen wird, ist unten beschrieben. Dieser Leseprozess wird nach jedem Create- und Deletecall aufgerufen und aktualisiert. Somit auch die Daten aus dem SAP-Backend und der IndexedDB. Das Event S1 symbolisiert den Start des Leseprozesses.

Create und Delete-Call Event

View1.controller.js

Ladevorgang über das Table Model starten:

Copy to Clipboard

oData.js

Die read-Funktion wird ausgeführt. Im „Success“-Fall, wird das Leseergebnis an die „_readSuccessCallback“-Methode weitergeleitet, um zu prüfen ob unter demselben Pfad auch lokal Daten abgelegt sind.

Copy to Clipboard

IndexedDb.js

getTable prüft zunächst, ob unter dem gelesenen sPath auch lokal eine Tabelle vorhanden ist. Ist dies der Fall, wird jeder Eintrag gelesen und zurückgegeben. Jeder Eintrag bekommt ein zusätzliches Attribut zur Herkunftsbestimmung.

Copy to Clipboard

Nach dem Lesevorgang zeigt die Tabelle, die aus dem Backend und von der IndexedDB gelesenen Daten, an.

Item List indexedDB

Nun ist es soweit, dass die Daten sowohl online als auch offline gelesen werden. Der nächste Beitrag der zweiteiligen Beitragsreihe von Tobias Gube beschäftigt sich mit dem Anlegen und Löschen von Daten. Sowohl online als auch offline. Anschließend werden diese mithilfe der IndexedDB synchronisiert.

Inhalt Expertblog Teil 2/2 ab dem 21.07.

  1. Daten anlegen: Offline
  2. Daten löschen: Offline
  3. Synchronisierung
  4. Ausblick