Zum Hauptinhalt
Klarnode
DE EN
Kontakt aufnehmen
Blog
Technischer Leitfaden

Offline-First-Architektur für Außendienst-Apps

10. Juni 2026 Klarnode Team ~3 Min. Lesezeit

Warum Offline-First?

Außendienstmitarbeiter:innen arbeiten dort, wo es kein verlässliches Internet gibt: im Lager, im Keller, auf dem Land, in der Fabrikhalle. Eine App, die bei schlechter Verbindung nicht funktioniert, wird nicht genutzt — egal wie gut die Funktionen sind.

Offline-First bedeutet: Die App funktioniert vollständig ohne Internetverbindung. Synchronisation passiert automatisch, sobald eine Verbindung besteht.

Architekturentscheidungen

Lokale Datenbank

Die zentrale Entscheidung: Welche Datenbank läuft auf dem Gerät?

  • SQLite / Room (Android) / Core Data (iOS): Bewährt, performant, volle SQL-Abfragen. Ideal für strukturierte Daten mit komplexen Relationen.
  • Realm / WatermelonDB: Reactive, object-orientiert, gute Change-Tracking-Unterstützung.

Für eine Außendienst-Plattform mit 70+ Datendomänen und SAP-Integration ist SQLite die robustere Wahl: bewährt, performant und mit voller SQL-Unterstützung.

Sync-Strategie

Delta Sync ist der Standard: Nur geänderte Datensätze werden übertragen, nicht der gesamte Datenbestand.

Drei Sync-Richtungen:

  1. Server → Client (Pull): Stammdaten, Preislisten, Routenpläne
  2. Client → Server (Push): Bestellungen, Besuchsberichte, Fotos
  3. Bidirektional: Kundendaten, die vor Ort aktualisiert werden

Konfliktlösung

Was passiert, wenn zwei Personen denselben Datensatz offline ändern?

  • Last-Write-Wins: Einfach, aber Datenverlust möglich. Akzeptabel für unkritische Felder.
  • Field-Level Merge: Änderungen auf Feldebene zusammenführen. Aufwändiger, aber datenverlustfrei.
  • Manuelle Konfliktlösung: Nutzer:in entscheidet. Nur für wenige, kritische Felder sinnvoll.

In der Praxis bewährt sich ein hybrider Ansatz: Field-Level Merge als Standard, Last-Write-Wins für Metadaten, manuelle Lösung für Preisänderungen.

Entwurfsmuster

Optimistic UI

Aktionen werden sofort in der lokalen Datenbank gespeichert und in der UI reflektiert — ohne auf Server-Bestätigung zu warten. Fehlgeschlagene Syncs werden in einer Retry-Queue gesammelt.

Queue-Based Sync

Alle Schreiboperationen landen in einer persistenten Queue. Ein Background-Service arbeitet die Queue ab, sobald eine Verbindung besteht. Idempotente Operations verhindern Duplikate.

Chunked Initial Sync

Der erste Sync (Onboarding) kann bei 70+ Datendomänen mehrere Minuten dauern. Lösung: priorisierte Chunks. Die wichtigsten Daten (Route des Tages, Top-Kunden) werden zuerst geladen.

SAP-Integration

Außendienst-Plattformen in der FMCG-Branche müssen mit SAP sprechen. Typische Integrationspunkte:

  • SAP SD: Aufträge, Kunden, Konditionen
  • SAP MM: Bestände, Materialdaten
  • SAP BW: Reporting-Daten, KPIs

Die Integration erfolgt über eine Middleware-Schicht, die SAP-IDocs oder OData-Services in das App-Datenmodell transformiert. Direkte SAP-Calls vom mobilen Gerät sind ein Anti-Pattern.

Lessons Learned

  1. Testen Sie offline zuerst: Wenn die App offline funktioniert, funktioniert sie auch online. Umgekehrt nicht.
  2. Sync-Monitoring ist Pflicht: Ein Dashboard, das zeigt, welche Geräte wann zuletzt synchronisiert haben.
  3. Datenvolumen im Blick behalten: 70 Datendomänen × tausende Kunden = mehrere hundert MB. Speicher und Sync-Dauer budgetieren.
  4. Fotos separat synchronisieren: Bilder sind groß und unkritisch für die sofortige Verarbeitung. Separate Queue mit niedrigerer Priorität.
  5. Rollback-Strategie: Was passiert, wenn ein Sync fehlschlägt? Lokale Daten dürfen nie verloren gehen.

Fazit

Offline-First ist kein Feature, sondern eine Architekturentscheidung, die das gesamte Systemdesign beeinflusst. Der Aufwand lohnt sich: Außendienst-Apps, die offline zuverlässig funktionieren, haben signifikant höhere Akzeptanz und Datenqualität.

Weiterlesen

Verwandte Artikel

Bringen wir Klarheit in Ihre Systeme.

Sprechen Sie mit uns über Ihr Vorhaben — wir antworten klar und konkret.

Kontakt aufnehmen