Funktioniert Ihre selbstgehostete Business-App offline? Eine praktische Checkliste zur Bewertung
Erfahren Sie, wie Sie testen, ob eine selbstgehostete Business-App wirklich Offline-Arbeit unterstützt – statt lediglich zwischengespeicherte Seiten anzuzeigen. Prüfen Sie Synchronisierung, Konflikte, Authentifizierung, Anhänge und Geräterisiken.
Klären Sie zunächst, was „offline“ für Ihr Team bedeutet
Die Anforderungen an den Offline-Betrieb unterscheiden sich. Eine kurze WLAN-Unterbrechung bei einem Termin vor Ort ist etwas anderes als eine ganze Schicht ohne zuverlässige Verbindung. Beides unterscheidet sich wiederum von der Arbeit an einem Standort, an dem mehrere Tage lang voraussichtlich keine Verbindung verfügbar ist.
Halten Sie fest, wie lange die längste wahrscheinliche Unterbrechung dauert, wie viele Personen gleichzeitig offline arbeiten könnten, welche Daten sie benötigen und wie schnell Änderungen Kolleginnen und Kollegen erreichen müssen. Berücksichtigen Sie die tatsächlich verwendeten Geräte und Browser: Das Offline-Verhalten kann je nach Anwendung und Browser variieren, und Funktionen für die Hintergrundsynchronisierung des Browsers sind nicht überall verfügbar ([MDN: Background Synchronization API](https://developer.mozilla.org/en-US/docs/Web/API/Background_Synchronization_API)).
Legen Sie fest, welche Wiederherstellungszeit akzeptabel ist. Entscheiden Sie beispielsweise, ob Mitarbeitende eine Aufgabe sofort offline abschließen müssen oder ob es ausreicht, einen Entwurf zu speichern und ihn nach Wiederherstellung der Verbindung fertigzustellen. Das sind unterschiedliche Anforderungen, die zu unterschiedlichen Tools führen können.
- Gelegentliche Unterbrechung: Die App sollte laufende Arbeit erhalten und sich nach Wiederherstellung der Verbindung zuverlässig davon erholen.
- Längere Unterbrechung: Nutzerinnen und Nutzer müssen möglicherweise auf eine sinnvolle Auswahl an Datensätzen zugreifen, sie bearbeiten und Aktionen später absenden können.
- Kein zuverlässiger Internetzugang: Prüfen Sie, ob eine offlinefähige App oder eine lokale Bereitstellung erforderlich ist, statt anzunehmen, dass ein cloudgehosteter Dienst den Bedarf abdeckt.
Unterscheiden Sie zwischen zwischengespeichertem Zugriff und dem Abschließen eines Arbeitsablaufs
Dass eine Seite offline geöffnet werden kann, beweist nicht, dass sich die Arbeit auch abschließen lässt. Eine Web-App kann Seitenressourcen oder zuvor aufgerufene Inhalte zwischenspeichern. Wie einzelne Anfragen verarbeitet werden, bestimmt jedoch die Anwendung. Zwischengespeicherte Seiten können veraltet, unvollständig oder schreibgeschützt sein ([MDN: Offline- und Hintergrundbetrieb](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Offline_and_background_operation)).
Testen Sie die gesamte Aufgabe, nicht nur die Bildschirmansicht. Kann eine Person den richtigen Datensatz finden, bearbeiten, eine Notiz hinzufügen, die Änderung absenden und offline eine eindeutige Bestätigung erhalten? Speichert die App lokal einen Entwurf, reiht sie eine Anfrage zur späteren Übermittlung ein oder zeigt sie lediglich eine Fehlermeldung an? Bitten Sie den Anbieter, das genaue Verhalten für jede kritische Aktion zu erläutern.
Betrachten Sie die folgenden Möglichkeiten als separate Funktionen: zuvor gespeicherte Inhalte anzeigen, sie offline bearbeiten, Änderungen für später vormerken und einen Arbeitsablauf vollständig ohne Serververbindung abschließen. Leiten Sie nicht eine Fähigkeit aus einer anderen ab.
- Offline-Zugriff: Welche Datensätze und Referenzseiten sind verfügbar, und wann wurden sie zuletzt aktualisiert?
- Offline-Bearbeitung: Welche Felder oder Aktionen lassen sich ohne Verbindung ändern?
- Vorgemerkte Übermittlung: Wo wird die ausstehende Änderung gespeichert, und woran erkennt die nutzende Person, dass sie den Server noch nicht erreicht hat?
- Abschluss des Arbeitsablaufs: Welche Schritte benötigen weiterhin den Server, etwa eine Genehmigung, Validierung oder die Erstellung eines gemeinsam nutzbaren Ergebnisses?
Erstellen Sie eine Liste der benötigten Datensätze, Anhänge und Referenzmaterialien
Erstellen Sie eine kurze Bestandsaufnahme, die sich an der tatsächlichen Arbeit orientiert, statt allgemein einen „Offline-Modus“ zu verlangen. Benennen Sie die konkreten Datensatztypen, die zu ändernden Felder und die benötigten Referenzinformationen. Berücksichtigen Sie Anhänge wie Fotos oder Dokumente und testen Sie diese unabhängig von gewöhnlichem Text.
Fragen Sie, wie Nutzerinnen und Nutzer Daten auswählen, die vor dem Offline-Arbeiten verfügbar sein sollen. Werden sie automatisch heruntergeladen, oder muss eine Person sie vorher öffnen oder auswählen? Prüfen Sie, ob die Datensätze während der gesamten erwarteten Offline-Zeit verfügbar bleiben und ob die App das Alter der lokal gespeicherten Daten anzeigt.
Der Speicherplatz im Browser ist begrenzt und unterscheidet sich je nach Browser und Gerät. Bei knappem Speicherplatz können gespeicherte Daten entfernt werden. Prüfen Sie, ob die App verständlich mit fehlenden lokalen Daten umgeht, und klären Sie, ob es für den Betrieb akzeptabel ist, Datensätze oder Anhänge vor Arbeitsbeginn erneut herunterladen zu müssen ([MDN: Speicherquoten und Kriterien für das Entfernen von Daten](https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria)).
- Ermitteln Sie die erforderlichen Datensätze und die Mindestfelder, die zum Handeln benötigt werden.
- Listen Sie benötigte Fotos, Dateien, Formulare, Karten, Verfahren oder sonstige Referenzmaterialien auf.
- Prüfen Sie das ungefähre Volumen der offline benötigten Daten und den verfügbaren Gerätespeicher.
- Testen Sie, ob die App anzeigt, welche Daten heruntergeladen wurden und wann sie zuletzt aktualisiert wurden.
- Legen Sie fest, was Nutzerinnen und Nutzer tun sollen, wenn erforderliche Offline-Inhalte fehlen.
Prüfen Sie Synchronisierung, erneute Versuche und Konfliktbehandlung
Eine vorgemerkte Aktion wird nicht zwangsläufig zuverlässig synchronisiert. Klären Sie, wodurch die Synchronisierung ausgelöst wird: durch einen automatischen Browserprozess, das Öffnen der App, das Drücken einer Synchronisierungsschaltfläche durch die nutzende Person oder einen anderen Schritt. Die Hintergrundsynchronisierung wird nicht von jedem gängigen Browser unterstützt. Testen Sie daher die konkreten Kombinationen, die Ihr Team verwendet ([MDN: Background Synchronization API](https://developer.mozilla.org/en-US/docs/Web/API/Background_Synchronization_API)).
Fragen Sie, was geschieht, wenn die Verbindung während eines Uploads abbricht oder die App nicht feststellen kann, ob eine Anfrage den Server erreicht hat. Wird eine zustandsändernde Aktion wiederholt, kann das zu doppelten Auswirkungen führen – es sei denn, die Anwendung kann eine Wiederholung zuverlässig erkennen oder feststellen, ob der erste Versuch erfolgreich war. Testen Sie Aktionen wie das Erstellen eines Datensatzes, das Absenden eines Formulars oder das Hochladen eines Anhangs auf doppelte Ergebnisse ([RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html)).
Konflikte können entstehen, wenn jemand einen Datensatz online bearbeitet, während eine andere Person eine Offline-Kopie ändert. Die Anwendung braucht dafür ein festgelegtes Verfahren: Sie kann konkurrierende Versionen anzeigen, Änderungen zusammenführen oder eine Person auffordern, die Änderungen zu prüfen und erneut zu bearbeiten. Legen Sie fest, welche Daten Vorrang haben, wer den Konflikt löst und ob die ursprünglichen Werte zur Überprüfung verfügbar bleiben ([Apache CouchDB: Replikation und Konfliktmodell](https://docs.couchdb.org/en/stable/replication/conflicts.html)).
- Können Nutzerinnen und Nutzer ausstehende, abgeschlossene und fehlgeschlagene Synchronisierungsaktionen sehen?
- Werden fehlgeschlagene Uploads erneut versucht, und kann eine Person sie gefahrlos manuell wiederholen?
- Wie verhindert die App doppelte Datensätze oder wiederholte Übermittlungen?
- Was geschieht, wenn sich derselbe Datensatz auf zwei Geräten ändert, bevor diese wieder verbunden sind?
- Kann eine Person Konflikte prüfen und lösen, oder wendet die App automatisch eine Regel an?
- Was geschieht, wenn der Browser oder das Gerät geschlossen wird, bevor die vorgemerkte Arbeit gesendet wurde?
Testen Sie Authentifizierung, Berechtigungen und gemeinsam genutzte Geräte
Beziehen Sie Anmelde- und Zugriffskontrollszenarien in die Bewertung ein. Klären Sie, ob eine Person bereits heruntergeladene Daten noch öffnen kann, wenn eine Authentifizierungssitzung abgelaufen ist, und was die App bis zur erneuten Verbindung zulässt. Ein offline befindliches Gerät kann den Server nicht nach zwischenzeitlich geänderten Berechtigungen fragen. Prüfen Sie daher, wie die Anwendung mit dieser Lücke umgeht und wie schnell Änderungen nach der erneuten Verbindung wirksam werden.
Achten Sie besonders auf gemeinsam genutzte Geräte und Geräte im Schichtbetrieb. Stellen Sie fest, ob eine Person lokal gespeicherte Datensätze oder ausstehende Änderungen einer anderen Person sehen kann, was beim Abmelden mit lokalen Daten geschieht und wie Nutzerinnen und Nutzer ihre eigenen noch nicht gesendeten Änderungen erkennen. Gehen Sie nicht davon aus, dass ein Anmeldebildschirm Informationen schützt, die bereits im Browser gespeichert sind.
Der Offline-Zugriff erzeugt eine lokale Kopie geschäftlicher Informationen. OWASP warnt davor, dass Personen mit Zugriff auf ein Gerät möglicherweise auf im Browser gespeicherte Daten zugreifen können, und rät davon ab, sensible Informationen oder Sitzungskennungen im lokalen Speicher abzulegen ([OWASP: HTML5 Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html)). Fragen Sie den Anwendungsanbieter, welche Daten auf dem Gerät gespeichert werden, und beurteilen Sie, ob dies für Ihre Daten angemessen ist.
- Testen Sie abgelaufene Sitzungen sowohl online als auch offline.
- Testen Sie eine Änderung von Berechtigungen, die Deaktivierung eines Kontos und die Abmeldung einer Person; stellen Sie anschließend die Verbindung wieder her.
- Prüfen Sie, ob eine Person, die ein Gerät verwendet, auf zwischengespeicherte Daten oder vorgemerkte Aktionen anderer Personen zugreifen kann.
- Dokumentieren Sie, wie sensibel die lokal gespeicherten Datensätze sind und wer Zugriff auf das Gerät hat.
Berücksichtigen Sie Anhänge und den Verlust von Geräten in der Risikobewertung
Offline-Unterstützung ist auch eine Frage der Datenverwaltung. Auf einem Gerät können Datensätze und Anhänge liegen, die noch nicht auf dem Server gespeichert sind. Legen Sie fest, welche Informationen lokal gespeichert werden dürfen, wie lange sie dort verbleiben dürfen und welche Nutzerinnen und Nutzer sowie Geräte sie mitführen dürfen.
Fragen Sie, ob lokale Daten verschlüsselt sind und welche Gerätekontrollen Ihre Organisation verlangt. Die Leitlinien von NIST zu Mobilgeräten empfehlen die Verschlüsselung gespeicherter Daten und beschreiben das Fernlöschen als Maßnahme für den Fall, dass ein Gerät verloren geht, gestohlen wird oder anderweitig in unbefugte Hände gerät ([NIST: Guidelines for Managing the Security of Mobile Devices in the Enterprise](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r2.pdf)). Prüfen Sie, ob Ihr Geräteverwaltungsprozess die Anforderungen für die tatsächlich von Mitarbeitenden verwendeten Geräte erfüllt.
Dokumentieren Sie das Vorgehen bei einem verlorenen Gerät. Berücksichtigen Sie, wie der Verlust gemeldet wird, wie sich der Zugriff nach Möglichkeit sperren lässt, wie lokal gespeicherte Daten behandelt werden und ob nicht synchronisierte Arbeit verloren gehen könnte. Die Offline-Funktion der Anwendung ersetzt nicht die Verfahren Ihrer Organisation zu Zugriff, Aufbewahrung und Sicherheitsvorfällen.
- Klassifizieren Sie die Daten und Anhänge, die auf den einzelnen Geräten gespeichert werden könnten.
- Legen Sie Anforderungen an Geräteverschlüsselung, Bildschirmsperre und Geräteverwaltung fest, die Ihrer Organisation entsprechen.
- Klären Sie, welche Fernmaßnahmen verfügbar sind und welche Daten sie entfernen können beziehungsweise nicht entfernen können.
- Legen Sie fest, wie Mitarbeitende ein verlorenes Gerät melden und wie ausstehende Arbeit wiederhergestellt oder neu erstellt wird.
Führen Sie einen kontrollierten Offline-Test mit typischen Arbeitsaufgaben durch
Verwenden Sie ein Testkonto, repräsentative Datensätze sowie dieselben Browser und Gerätemodelle, die Ihr Team nutzen möchte. Stellen Sie zunächst eine Verbindung her, bereiten Sie die Daten vor, die offline verfügbar sein sollen, und prüfen Sie, was die App als verfügbar anzeigt. Trennen Sie dann bewusst die Netzwerkverbindung und führen Sie die vereinbarten kritischen Aufgaben aus.
Stellen Sie die Verbindung wieder her und warten Sie auf den dokumentierten Auslöser für die Synchronisierung. Prüfen Sie sowohl die Benutzeroberfläche als auch das Ergebnis auf dem Server: Bestätigen Sie, dass die vorgesehenen Änderungen angekommen sind, fehlgeschlagene Vorgänge sichtbar sind, Anhänge vollständig übertragen wurden und keine Aktion doppelt ausgeführt wurde. Wiederholen Sie den Test mit einem Konflikt und einem unterbrochenen Upload. Halten Sie die genauen Schritte und Ergebnisse fest, damit das Team den Test nach Konfigurations- oder Anwendungsänderungen wiederholen kann. Ein Test mit unterbrochener Verbindung und anschließender Prüfung der erneut ausgeführten Anfragen folgt auch der Testmethode von [Chrome for Developers: Erneutes Versuchen von Anfragen nach Wiederherstellung der Verbindung](https://developer.chrome.com/docs/workbox/retrying-requests-when-back-online).
Testen Sie nicht nur eine ideale, kurze Unterbrechung. Berücksichtigen Sie die erwartete maximale Offline-Zeit sowie Situationen wie das Schließen und erneute Öffnen des Browsers, einen Neustart des Geräts oder einen Benutzerwechsel, sofern diese zum normalen Betrieb gehören.
- Erstellen Sie für jeden kritischen Arbeitsablauf eine Test-Checkliste mit dem erwarteten Ergebnis.
- Trennen Sie die Netzwerkverbindung und führen Sie den Arbeitsablauf von Anfang bis Ende durch.
- Unterbrechen Sie mindestens einen Upload oder eine Übermittlung und stellen Sie anschließend die Verbindung wieder her.
- Prüfen Sie auf fehlende Änderungen, doppelte Auswirkungen, ungelöste Konflikte und klare Rückmeldungen an die nutzende Person.
- Wiederholen Sie den Test für jede Browser- und Gerätekombination, auf die das Team angewiesen sein wird.
- Dokumentieren Sie Einschränkungen und entscheiden Sie, ob sie akzeptabel sind, eine Umgehungslösung erfordern oder die App ausschließen.
Wählen Sie das Bereitstellungsmodell, das zur Arbeit passt
Selbsthosting beschreibt, wer die Anwendungsumgebung betreibt. Es stellt für sich genommen weder Offline-Daten noch Offline-Bearbeitung oder Synchronisierung bereit. Eine auf einem Server gehostete App benötigt weiterhin eine Verbindung, wenn ihr Arbeitsablauf von diesem Server abhängt. Umgekehrt kann eine Anwendung mit sorgfältig entwickeltem Offline-Verhalten ausgewählte Aufgaben ohne Verbindung unterstützen – innerhalb ihrer jeweiligen Grenzen.
Airbip verwaltet die Cloud-Infrastruktur für selbstgehostete Anwendungen: Anwendungsinstanzen werden als Docker-Workloads auf Airbip-Cloud-Servern ausgeführt. Routing und TLS-Zertifikate werden über Traefik und Let’s Encrypt automatisiert. Hinzu kommen DNS-Prüfungen, die Verwaltung des Dienstlebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Backups. Dieses Hosting-Modell ergänzt eine Anwendung nicht um Offline-Funktionen. Bewerten Sie das dokumentierte Verhalten der App unabhängig davon und prüfen Sie, ob die Standorte der Nutzerinnen und Nutzer den gehosteten Dienst erreichen können, wenn sie online arbeiten.
Wenn Mitarbeitende an Orten ohne zuverlässige Verbindung unverzichtbare Aufgaben erledigen müssen, wählen Sie eine Anwendung und ein Bereitstellungsmodell, das diese Arbeitsabläufe nachweislich unterstützt, oder entwickeln Sie ein ausdrücklich festgelegtes Offline-Verfahren. Wenn nur gelegentliche Unterbrechungen relevant sind, kann ein getesteter Ablauf mit vorgemerkten Änderungen und späterer Synchronisierung ausreichen. Wenn für die Arbeit sofortige gemeinsame und serverseitig validierte Aktionen nötig sind, kann ein reiner Online-Ablauf mit einer klaren Ausweichlösung sicherer sein, als zu behaupten, der Arbeitsablauf funktioniere offline.
- Wählen Sie offlinefähige Software, wenn kritische Aufgaben ohne Serververbindung erledigt werden müssen.
- Wählen Sie einen getesteten Ablauf mit späterer Synchronisierung nur dann, wenn sein Umgang mit Konflikten und doppelten Aktionen akzeptabel ist.
- Wählen Sie einen ausdrücklich nur online vorgesehenen Ablauf, wenn Aktionen eine Live-Validierung durch den Server oder gemeinsam genutzte aktuelle Daten erfordern, und stellen Sie bei Ausfällen eine praktikable Ausweichlösung bereit.
- Behandeln Sie Hosting, Anwendungsfunktionen, lokale Gerätekontrollen und Verfahren für Mitarbeitende als getrennte Bestandteile der Entscheidung.
Häufige Fragen
Ist eine Business-Anwendung durch Selbsthosting offline verfügbar?
Nein. Selbsthosting betrifft den Ort und die Art des Betriebs der Anwendung. Offline-Zugriff und Synchronisierung hängen vom Design der Anwendung und den auf dem Gerät der nutzenden Person verfügbaren Daten ab. Benötigt eine selbstgehostete App für eine Aufgabe ihren Server, ist für diese Aufgabe weiterhin eine Verbindung erforderlich.
Reicht eine zwischengespeicherte Seite aus, um eine App als offlinefähig zu bezeichnen?
Nein. Zwischengespeicherte Ressourcen oder Seiten können zwar dafür sorgen, dass bestimmte Inhalte angezeigt werden, beweisen aber nicht, dass Nutzerinnen und Nutzer Datensätze bearbeiten, Aktionen absenden, Dateien hochladen oder einen Arbeitsablauf abschließen können. Testen Sie jede kritische Aufgabe ohne Verbindung und prüfen Sie das Ergebnis nach Wiederherstellung der Verbindung.
Können vorgemerkte Offline-Aktionen zu Duplikaten führen?
Das ist möglich, wenn eine Aktion nach einem unklaren Fehler erneut versucht wird und die Anwendung nicht zuverlässig feststellen kann, ob sie bereits erfolgreich war. Testen Sie wiederholte Übermittlungen und unterbrochene Verbindungen und fragen Sie, wie die App mit erneuten Versuchen umgeht und Duplikate verhindert.
Was sollten wir testen, wenn eine Offline-Bearbeitung mit einer Online-Bearbeitung in Konflikt gerät?
Ändern Sie denselben Datensatz auf zwei Geräten oder durch zwei Personen, wobei eine Änderung offline vorgenommen wird. Prüfen Sie nach Wiederherstellung der Verbindung, ob die App beide Versionen anzeigt, Änderungen zusammenführt oder eine Überprüfung verlangt. Stellen Sie außerdem sicher, dass Nutzerinnen und Nutzer das Ergebnis erkennen und den Konflikt lösen können.
Ist Browser-Speicher für wichtige Offline-Daten zuverlässig genug?
Gehen Sie nicht davon aus, ohne dies zu testen. Speichergrenzen und das Verhalten beim Entfernen von Daten unterscheiden sich je nach Browser; bei knappem Speicherplatz können Daten gelöscht werden ([MDN: Speicherquoten und Kriterien für das Entfernen von Daten](https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria)). Klären Sie, wie die App Offline-Daten vorbereitet und schützt, und testen Sie anschließend, ob sie während des von Ihrem Team erwarteten Zeitraums auf den vorgesehenen Geräten verfügbar sind.
Was sollte geschehen, wenn ein Gerät mit Offline-Daten verloren geht?
Legen Sie ein dokumentiertes Vorgehen fest, das Meldung, Zugriffskontrolle, Geräteverwaltung und lokal gespeicherte Daten berücksichtigt. Bewerten Sie Verschlüsselung und Möglichkeiten zum Fernlöschen ([NIST: Leitlinien zur Sicherheit mobiler Geräte in Unternehmen](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r2.pdf)) und entscheiden Sie, wie mit Arbeit umgegangen wird, die noch nicht synchronisiert war.
Quellen und weiterführende Literatur
- Offline and background operation — Progressive web apps — MDN Web Docs
- Background Synchronization API — MDN Web Docs
- Retrying requests when back online — Chrome for Developers
- Storage quotas and eviction criteria — MDN Web Docs
- HTML5 Security Cheat Sheet — OWASP
- RFC 9110: HTTP Semantics — Internet Engineering Task Force
- Replication and conflict model — Apache CouchDB
- Guidelines for Managing the Security of Mobile Devices in the Enterprise — National Institute of Standards and Technology
- Service Worker API — MDN Web Docs