Offline-fähige Anwendung: weiterarbeiten ohne Netz

Eine offline-fähige Anwendung arbeitet weiter, wenn die Verbindung zum Server fehlt, und gleicht ihre Daten ab, sobald sie zurück ist. In Halle und Lager ist das keine Kür: Metallregale, Kühlbereiche und Wartungsfenster erzeugen regelmäßig Lücken, in denen trotzdem gefertigt und gebucht wird.

Offline-Fähigkeit: was der Begriff verlangt

Drei Eigenschaften gehören zusammen. Die Anwendung startet und bedient sich ohne Server, weil Programm und Stammdaten lokal liegen. Sie nimmt Eingaben entgegen und speichert sie dauerhaft auf dem Gerät, sodass ein Neustart nichts verliert. Und sie meldet dem Bedienenden ehrlich ihren Zustand: verbunden, getrennt, wie viele Vorgänge warten.

Der dritte Punkt wird am häufigsten übersehen. Ein Gerät, das im getrennten Zustand genauso aussieht wie im verbundenen, erzeugt falsches Vertrauen; der Bediener erfährt vom Problem erst, wenn die Zahlen nicht stimmen. Ein sichtbarer Zustand mit Zähler der wartenden Meldungen kostet wenig und verhindert die meisten Streitfälle.

Lokale Speicherung und Nachlauf der Buchungen

Technisch entsteht eine Warteschlange auf dem Gerät: Jede Eingabe wird als vollständiger Vorgang mit eigener Kennung und Zeitstempel abgelegt und bleibt dort, bis der Server den Empfang bestätigt hat. Erst dann wird sie entfernt. Weil dieselbe Meldung nach einer Störung mehrfach ankommen kann, muss die Gegenseite die Kennung kennen und Wiederholungen verwerfen — dieselbe Regel, die auch die Schnittstelle zum ERP-System trägt.

Für Stammdaten gilt die umgekehrte Richtung: Artikel, Lagerplätze und offene Aufträge werden vorgeladen und in Abständen erneuert. Der Umfang gehört begrenzt, sonst wird jeder Start zur Wartezeit. Üblich ist ein Ausschnitt entlang der Arbeit des Geräts: die Aufträge dieser Schicht, die Plätze dieser Halle.

Für den Betrieb heißt das: Der getrennte Zustand ist kein Fehler, sondern ein vorgesehener Betriebsmodus mit eigenen Regeln. Wer ihn so behandelt, plant ihn im Entwurf ein; wer ihn als Ausnahme behandelt, lernt seine Regeln erst im Schadensfall kennen.

Konflikte beim Zusammenführen auflösen

Zwei Geräte können denselben Bestand verändert haben, während beide getrennt waren. Für Mengen ist die Lösung meist einfach: Buchungen sind Veränderungen, nicht absolute Werte, und lassen sich addieren. Kritisch sind Vorgänge, die Ausschließlichkeit verlangen — Kommissionierung derselben Position, Sperre einer Charge, Zählung eines Platzes bei der Inventur mit mobilen Geräten.

Dafür braucht es eine vorher festgelegte Regel: Wer zuerst bestätigt wurde, gewinnt; der zweite Vorgang landet in einer Klärliste mit Nachricht an den Meister. Eine Anwendung, die Konflikte still auflöst, ist gefährlicher als eine, die sie meldet.

Wo Offline-Betrieb an seine Grenze stößt

Nicht jeder Vorgang darf ohne Server laufen. Alles, was eine Freigabe in der Gegenwart braucht — Sperrentscheidung, Preisbildung, Kreditprüfung, sicherheitsrelevante Quittierung an der Anlage —, gehört an die Verbindung gebunden. Auch die Dauer ist zu begrenzen: Ein Gerät, das seit Tagen nicht abgeglichen hat, arbeitet mit veralteten Beständen und sollte den Bediener warnen oder bestimmte Vorgänge sperren.

Eine dritte Grenze ist der Umfang der lokalen Daten. Ein Handgerät kann nicht den gesamten Artikelstamm eines Großhändlers führen, und es soll es auch nicht: Je mehr Stammdaten mitgeführt werden, desto länger dauert der Abgleich und desto älter sind die Werte im Schnitt. Der Ausschnitt richtet sich nach der Arbeit des Geräts, und was außerhalb liegt, wird bewusst als nicht verfügbar angezeigt statt stillschweigend weggelassen. Auch der Speicherplatz gehört überwacht: Eine volle Warteschlange darf keine Eingabe verschlucken, sondern muss die Erfassung anhalten und das melden.

Typische Fehler im Entwurf

Erstens: Die lokale Speicherung wird erst nachträglich eingebaut. Nachrüsten heißt fast immer, die Datenhaltung umzubauen. Zweitens: Die Uhr des Geräts wird als Wahrheit genommen, obwohl sie abweicht — der Zeitpunkt der Aufnahme gehört ebenso protokolliert wie der Eingang beim Server. Drittens: Es gibt keinen Weg, eine hängende Warteschlange zu sehen und zu leeren. Viertens: Der Test findet im Büro statt, wo das Netz stabil ist; geprüft wird zwischen den Regalen, mit abgeschaltetem Zugangspunkt.

Wie wir eine solche Anwendung bauen

Wir entwerfen die Warteschlange vor der Oberfläche, legen Kennung und Regel für Wiederholungen fest und prüfen die Abnahme mit gezogenem Stecker: Netz aus, zwanzig Vorgänge erfassen, Gerät neu starten, Netz an, Ergebnis im ERP vergleichen. Gebaut wird das in der Softwareentwicklung für Fertigung und Lager, die Übergabe an die Kontorseite in der Prozessautomatisierung zwischen Halle, Lager und ERP.