Maschinendaten offline speichern via SAP

Offline-Apps und Herausforderungen bei der Synchronisierung mit Backend-Systemen

| Autor / Redakteur: Daniel Raßbach* / Dr. Jürgen Ehneß

Immer mehr Maschinen erzeugen immer mehr Daten – wie speichert man diese offline?
Immer mehr Maschinen erzeugen immer mehr Daten – wie speichert man diese offline? (Bild: © metamorworks - stock.adobe.com)

Der Einsatz mobiler Apps im Unternehmen wächst. Im Privatgebrauch längst angekommen, halten sie auch in der deutschen Wirtschaft Einzug. Vorteile wie Zeitersparnis und Flexibilität liegen auf der Hand – doch mit der Mobilität kommen neue Herausforderungen wie die Datenspeicherung bei fehlender Internetverbindung auf.

Ein Instandhaltungsmitarbeiter sieht eine Schadensmeldung an einer Maschine und kann diese direkt an Ort und Stelle über ein mobiles Endgerät im SAP-System vermerken – ohne dafür zum Rechner am anderen Ende der Halle laufen zu müssen. Doch was passiert, wenn die Internetverbindung in diesem Teil der Halle nicht ausreicht und die Daten nicht übertragen werden? Oder wenn ein Vertriebsmitarbeiter im Außeneinsatz wichtige Daten speichern möchte, aber offline ist? In den unterschiedlichsten Business-Kontexten ist die Offline-Fähigkeit von Apps eine wichtige und unterschätzte Funktion.

Welche Technologien bieten sich für Offline-Apps im SAP-Umfeld an?

Die Standard-Technologie in der SAP-Mobility-Strategie ist SAP UI5. Viele kennen diese auch unter dem Namen „Fiori“ – genau genommen ist das aber nur die Designrichtlinie der SAP, wie Apps zu entwickeln sind. Darauf aufbauend können verschiedene Frameworks verwendet werden, um SAP-Fiori-Anwendungen auf das mobile Endgerät zu bringen und diese offline-fähig zu machen. Je nach Anwendungsfall bietet sich ein anderes Framework hierfür an: Mobile Services, Simplifier und Neptune sind drei davon.

Mobile Services ist ein Service in der SAP Cloud Platform (SCP), der speziell für die Entwicklung nativer Apps verwendet werden kann. Für diesen Service werden entsprechende Lizenzen benötigt. Mobile Services ist vom Entwicklungsaufwand der Offlinefähigkeit als Mittelmaß zwischen Neptune und Simplifier einzuordnen.

Simplifier, eine Low-Code-Plattform für Business-Apps, bietet die Möglichkeit einer direkten Maschinenanbindung sowie die Integration von Künstlicher Intelligenz und ist dort in der Entwicklung und Wartung sehr effizient. Die Offline-Fähigkeit wird jedoch nicht im Service mitgeliefert und ist aufwändiger zu programmieren als zum Beispiel bei Neptune und Mobile Services.

Die Plattform Neptune ist für einen typischen ABAP-Entwickler geeignet, da Schnittstellen zwischen Backend und Frontend vom Framework gegeben sind. Es bietet eine schnellere Entwicklung in Bezug auf die Offline-Fähigkeit, bringt aber – genauso wie Simplifier – Lizenzkosten mit sich.

Wie kommunizieren Offline-Apps?

Sobald in einer mobilen App eine Abfrage getätigt wird, kommuniziert diese direkt per OData Service mit dem Backend. Bei einer offline-fähigen App müssen die Daten aus dem Backend initial geladen und direkt auf dem mobilen Endgerät gespeichert werden, beispielsweise am Anfang eines Tages. Hier ist aus Datenschutzgründen wichtig, dass die Daten verschlüsselt gespeichert werden. Bei sicherheitskritischen Themen können verschiedene Autorisierungsmöglichkeiten verwendet werden, zum Beispiel die Notwendigkeit einer Anmeldung mit dem SAP-User und einem PIN-Code. Die Daten sind dann in der App verfügbar, liegen aber auf dem Gerätespeicher und nicht im Server. Wenn Daten während der Offline-Phase geändert werden, werden diese Änderungen zunächst auf dem Gerät gehalten und in das Backend überschrieben, sobald wieder eine Internetverbindung besteht.

Welche Herausforderungen gibt es bei der Offline-Datenspeicherung?

Die Synchronisierung wird schwierig, sobald mehrere Nutzer mit denselben Daten arbeiten. Beispielsweise ändert ein Mitarbeiter offline den Preis für ein Produkt in seiner mobilen App, aber sein Kollege hat gleichzeitig den Preis im Backend auf einen anderen Wert korrigiert. Wer „gewinnt“ hier?

Ein weiterer möglicher Use-Case: Ein Mitarbeiter möchte auf Daten zugreifen, die im Backend nicht mehr verfügbar sind. Er hat die Daten initial auf sein Endgerät geladen, ist dann einen Tag beim Kunden offline und arbeitet mit diesen Daten, die aber in der Zwischenzeit gelöscht wurden. Sobald er wieder online ist, möchte er die geänderten Daten zurückschreiben, die nicht mehr existieren.

Wie kann die Synchronisierungsproblematik gelöst werden?

Das ist von Fall zu Fall unterschiedlich – besonders im Hinblick darauf, wie sicherheitskritisch die Daten sind und ob der Nutzer dringend ein Feedback benötigt. Hier sind einige beispielhafte Möglichkeiten aufgelistet, wie mit der Herausforderung umgegangen werden kann:

1. Gewinnprinzip: Die letzte Änderung gewinnt generell. Dieses Prinzip ist das einfachste, aber je nach Business-Case nicht immer sinnvoll. Beispielsweise soll der bestehende Datensatz eines Instandhaltungsauftrag bearbeitet werden: Dort soll der technische Platz per App geändert werden. Mitarbeiter A hat diesen mit bestehender Internetverbindung verbucht. Mitarbeiter B hat den Platz ebenfalls geändert, war aber den ganzen Tag offline. Abends synchronisieren dann die Änderungen von Mitarbeiter B, sodass diese „gewinnen“ und letztlich im System sind.

2. Merch-Prinzip: Die verschiedenen Änderungen werden durch vorher definierte Regeln priorisiert. Das kann durch einen Algorithmus, manuell oder sogar mithilfe einer Künstlichen Intelligenz passieren. Zum Beispiel kann Mitarbeiter A nur den Preis ändern und Mitarbeiter B nur den Namen des Produktes.

3. Verweigerung: Es dürfen keine Daten bearbeitet werden, die beispielsweise innerhalb eines definierten Zeitraums bereits geändert wurden. Wenn ein Mitarbeiter das versucht, erhält er eine Fehlermeldung.

Sobald bei den oben genannten Methoden ein Fehler auftritt, muss dieser festgehalten und gegebenenfalls korrigiert werden. Dafür wird ein Error-Monitor im SAP-System integriert, der alle Buchungen listet und Fehler anzeigt. Ein Key-User, zum Beispiel ein Mitarbeiter im Controlling, sieht den Fehler und entscheidet, ob die Daten verbucht werden können oder ob Daten im Backend geändert werden müssen, bevor eine Synchronisierung stattfinden kann. So kann individuell entschieden werden. Der Endanwender erhält ebenfalls eine Fehlermeldung und weiß, dass der Fehler gelöst wird.

Unabhängig davon, für welches Prinzip sich ein Unternehmen entscheidet: Das oberste Ziel ist, dass keine Daten verloren gehen. In vielen Fällen gibt der Business-Case dem Unternehmen schon vor, wie die Lösung auszusehen hat.

Das Endgerät geht kaputt, bevor die Offline-Daten synchronisiert wurden. Sind die Daten verloren?

Ja. Bei der Nutzung von Offline-Apps im Unternehmenskontext wird geraten, mindestens morgens einmal die aktuellen Daten aus dem Backend zu synchronisieren und abends erneut, sobald tagsüber Daten auf dem mobilen Endgerät verbucht wurden.

Fazit

Offline-Apps in Unternehmen haben dort einen Nutzen, wo keine komplette Internetabdeckung vorhanden ist und Daten verloren gehen können. Wenn Unternehmen über ihre Mobility-Strategie nachdenken, sollten sie im Vorfeld die Key-Aspekte in der App-Entwicklung betrachten. Wie ist der Ist-Zustand, und was ist das Ziel? Wo liegen Potenziale? Welche Technologie soll verwendet werden? Wird eine Offline-Abdeckung benötigt? Wie soll mit den Übertragungsdaten umgegangen werden? Die Anforderungen können zum Beispiel im Rahmen eines Workshops genau definiert werden. Daraus ergeben sich dann Budget und Entwicklungszeit für das Projekt.

Weitere Informationen zum Thema Enterprise Mobility finden Sie auf der Website mission-mobile.de.

Daniel Raßbach (B. Sc.), Experte und zertifizierter Consultant bei www.mission-mobile.de
Daniel Raßbach (B. Sc.), Experte und zertifizierter Consultant bei www.mission-mobile.de (Bild: mindsquare)

*Der Autor: Daniel Raßbach ist zertifizierter SAP Consultant und Mobility-Experte des Fachbereichs Mission Mobile im IT-Beratungsunternehmen mindsquare. Er betreut dort verschiedenste Kunden zum Thema Konzeption und Entwicklung von Applikationen im mobilen SAP-Umfeld mit den Schwerpunkten Fiori, Neptune und Simplifier. Schon während seines Bachelor-Studiums in Informatik beschäftigte er sich mit IT-Themen der Zukunft, insbesondere mit Robotic und autonomem Fahren.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46294741 / Daten)