Offline arbeiten, ohne dass Daten doppelt entstehen

Eine Anwendung, die im Funkloch stehen bleibt, wird auf der zweiten Baustelle nicht mehr geöffnet. Der schwierige Teil daran ist aber nicht das Weiterarbeiten ohne Netz, sondern das Zusammenführen danach.

Das eigentliche Problem heißt Wiederholung

Ein Gerät ohne Verbindung sammelt Einträge und schickt sie später. Dabei geht regelmäßig etwas schief: Die Verbindung bricht mitten im Übertragen ab, das Gerät weiß nicht, ob der Server die Daten bekommen hat, und versucht es erneut. Wenn der Server dabei ein zweites Mal anlegt, entstehen Doppelbuchungen, und zwar genau dann, wenn das Netz schlecht ist, also ständig.

Die Sperre gehört in die Datenbank, nicht in den Programmcode

Es ist verlockend, vor dem Anlegen nachzusehen, ob die Kennung schon da ist. Das funktioniert, bis zwei Anfragen gleichzeitig kommen: Beide sehen nichts, beide legen an. Die Prüfung muss deshalb ein eindeutiger Schlüssel in der Datenbank sein. Dann kann die zweite Anfrage gar nicht anlegen, unabhängig davon, was der Programmcode denkt.

Dasselbe gilt für alles, was höchstens einmal passieren darf. In einer Fahrzeugverwaltung sollten Erinnerungen nicht doppelt verschickt werden. Gelöst ist das nicht durch eine Merkliste im Programm, sondern durch einen eindeutigen Schlüssel über Fahrzeug, Prüfart, Stufe, Fälligkeit, Empfänger und Tag. Ein zweiter Lauf des Nachtprozesses kann keine zweite Mail erzeugen.

Warum Uhrzeiten aus dem Gerät nichts entscheiden dürfen

Die naheliegende Regel für Konflikte lautet: Der neuere Eintrag gewinnt. Dafür bräuchte man eine verlässliche Uhr, und die gibt es auf einem Telefon nicht. Uhren gehen falsch, Zeitzonen wechseln, und manche Geräte stellen die Zeit beim Laden nach.

Deshalb entscheidet die Gerätezeit nichts. Sie wird mitgeführt als Angabe des Erfassers, weil sie fachlich interessant ist, aber die Reihenfolge und die Gültigkeit entstehen auf dem Server. Wo eine echte Konfliktentscheidung nötig ist, wird sie einem Menschen vorgelegt, statt sie zu erraten.

Was offline grundsätzlich nicht geht

• Fortlaufende Nummern. Eine lückenlose Rechnungs- oder Personalnummer kann nur eine Stelle vergeben. Offline erzeugte Nummern haben entweder Lücken oder Dubletten. Deshalb: Die Kennung für die Übertragung kommt aus dem Gerät, die fachliche Nummer vom Server.
• Prüfungen gegen den Gesamtbestand. Ob eine Kombination schon existiert, weiß das Gerät nicht. Solche Prüfungen laufen beim Abgleich, und dann muss die Anwendung eine Antwort dafür haben, dass ein Eintrag abgelehnt wird, statt ihn wegzuwerfen.
• Freigaben. Was eine zweite Person genehmigen soll, kann offline nur beantragt werden.

Reihenfolge und Sichtbarkeit

Die Warteschlange im Gerät wird in der Reihenfolge abgearbeitet, in der erfasst wurde. Sonst kommt ein Eintrag beim Server an, dessen Bezugsdatensatz noch fehlt, und der Fehler sieht aus wie ein Programmfehler, obwohl es ein Reihenfolgeproblem ist.

Und der Mensch am Gerät muss sehen, was noch nicht übertragen ist. Eine Anwendung, die stillschweigend puffert, erzeugt das schlechteste aller Gefühle: Der Nutzer weiß nicht, ob seine Arbeit angekommen ist, und erfasst zur Sicherheit noch einmal.

Der Zwischenspeicher für halbfertige Eingaben

Neben der Warteschlange für fertige Einträge braucht es einen Zwischenspeicher für unfertige. Eine Checkliste mit vierzig Punkten, halb ausgefüllt, darf nicht verschwinden, weil das Gerät in der Halle den Bildschirm sperrt oder der Browser die Seite aus dem Speicher wirft. Das ist technisch trivial und im Alltag der Unterschied zwischen Vertrauen und Misstrauen.

Wo das gebaut ist

Der Check-in an einer Laderampe nimmt Anmeldungen ohne Netz an und liefert sie nach (Fallstudie). Die Baustellen-App eines Elektrobetriebs erfasst Zeiten, Material und Unterschriften offline (Fallstudie). Die App einer Pflegeplattform arbeitet auf der Tour weiter und bucht beim Abgleich nichts doppelt. In allen drei Fällen ist es dieselbe Regel, nur in anderem Gewand.