scripte/MABEA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1e8d66f63614b25650072560cecaea12cdf9ecbd
MABEA/arbeitskacheln/19_satelliten_server.md
T
patrickandClaude Sonnet 5 9c6426190e docs(arbeitskacheln): Open-Source-/HiOrg-Vergleich ausgewertet, 14 neue Kacheln ausgearbeitet 
Vergleich mit InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS,
HiOrg-Server ergibt neue Kacheln (ASSET-010 Custody, FILE-008 Hash-Audit-Journal,
FILE-009 Notizen, NOTIF-003, MAINT-007 Tankbuch, ZUST-003 Standort-Scoping,
FOUND-007 Import/Export, FOUND-008 Fristen-Dienst, READY-006 Statistik-Dashboard,
UI2-006..010) sowie Referenz-Ergänzungen bei bestehenden Lücken. Alle Design-
Entscheidungen (Datenmodell, Sicherheitsanforderungen bei ASSET-010) geklärt.

Neues Epic 23 (Flutter-Begleit-App, Sondierungs-Prototyp FLUT-001) inkl. geklärtem
TLS-Blocker (Domain mabea.perlbach-edv.de mit Let's-Encrypt-Zertifikat statt
selbstsigniertem Server-Zertifikat).

Alle Kacheln bleiben offen/ungeplant, nur ausgearbeitet, keine Implementierung.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
2026-09-10 00:49:32 +02:00

4.5 KiB
Raw Blame History

Epic 19 — Satelliten-Server

Details zu SAT-001 (Platzhalter/Architektur-Vorbereitung). Übernommen aus arbeitskarten/13_satelliten_server.md (Karte 13) — die größte gefundene Lücke im 16-Epic-Backlog: eine bereits "entschieden" gewertete Architektur-Erweiterung mit konkreten Datenmodell-Konsequenzen, die in keinem der 16 ursprünglichen Epics erwähnt war.

SAT-001 — Hauptserver mit Satelliten-Servern

  • Ziel: Zusätzlich zum Hauptserver können Satelliten-Server existieren, die lokal (Einsatzort/Wache) laufen und temporär vom Hauptserver getrennt sind — für KatS- Einsatzlagen ohne Internet, Wachen mit dauerhaft schlechter Anbindung, oder reinen Ausfallschutz.
  • Beschreibung: Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon (gleiche Software/API/DB), kein reiner Cache — mehrere Mitarbeiter können gleichzeitig am Satelliten arbeiten. Autark-Dauer bewusst nicht zeitlich begrenzt (Stunden bis Tage). Konfliktvermeidung statt Konfliktlösung: jedes Objekt ist während einer Trennung fest genau einem Server zugeordnet (Haupt- oder ein bestimmter Satellit), am jeweils anderen für Schreibzugriffe gesperrt — dadurch strukturell kein "wer gewinnt"-Problem.
  • Benutzerwert: Betrieb bleibt auch bei längerem/vollständigem Verbindungsverlust einsatzfähig, ohne Datenkonflikte beim späteren Zusammenführen.
  • Abhängigkeiten: FOUND-002, ASSET-003, MOBILE-003 (Abgrenzung: Satellit ist die Lösung für ganze Standorte über längere Zeit, MOBILE-003 für Kurzzeit-Netzlücken innerhalb einer einzelnen Kontrolle)
  • Datenmodell: Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder Satelliten-ID), änderbar nur durch bewussten Auslagerungs-/Rückhol-Vorgang. IDs systemweit eindeutig von Anfang an (kein lokal generierter, kollisionsanfälliger Schlüssel) — Voraussetzung für widerspruchsfreies Zusammenführen. Sync überträgt neu entstandene Datensätze per Insert und geänderte bestehende Zeilen (offene Fehlbestände, aktive Mindermengen-Genehmigungen, Objektpositionen) per Upsert.
  • Backend: Auslagerungs-/Rückhol-Endpunkte, Sync-Logik (Insert+Upsert), Schreibsperre für ausgelagerte Objekte am Hauptserver
  • Frontend: Admin-UI zum Auslagern/Zurückholen
  • Mobile: kein Unterschied — Satellit spricht dieselbe API
  • QR-Code/Seriennummer/Inventarnummer: nein
  • Akte: zeigt ggf. aktuellen Server-Zuordnungsstatus
  • Rechte: Auslagerung/Rückholung: Administrator
  • Audit: Auslagerung/Rückholung geloggt, Sync-Vorgänge nachvollziehbar
  • Akzeptanzkriterien: Objekt an Satellit auslagern → am Hauptserver für Schreiben gesperrt; nach Rückholung sind alle am Satelliten entstandenen/geänderten Daten korrekt im Hauptserver.
  • Tests: Sync-Test (Insert neuer Datensätze + Upsert geänderter bestehender Zeilen), Schreibsperre-Test während Auslagerung.
  • DoD: DECISION REQUIRED zum Umsetzungszeitpunkt — Nutzer-Entscheidung aus früherer Session: "erstmal nur mit Hauptserver", also bewusst zurückgestellt. Offene Punkte vor Umsetzung: technischer Auslöser der Auslagerung (manuell vs. automatisch bei Verbindungsverlust), Vorab-Bestückung des Satelliten mit Stammdaten, Verhalten bei laufender Kontrolle während Auslagerung/Rückholung, Hardware-Anforderung.
  • Referenz (Open-Source-Vergleich 2026-09-09): Emergency Management Tool (projekt-katastrophenschutz/emergency-management-tool, verwaist seit 2016, nur als Konzeptbestätigung — keine brauchbare Codequalität) verfolgt unabhängig dieselbe Grundidee (Offline-first-Netzwerkbetrieb mit späterer Auto-Synchronisation zwischen Leitstellen-Instanzen). Bestätigt den Bedarf, liefert aber keine über SAT-001 hinausgehende Lösung — SAT-001s Konfliktvermeidung-statt-Konfliktlösung-Ansatz (feste Server-Zuordnung je Objekt) ist bereits ausgereifter als das, was dort skizziert ist.

MABEA-Ist-Stand-Abgleich: nicht umgesetzt, bewusst zurückgestellt (Nutzer-Entscheidung "erstmal nur mit main server gemacht"). Diese Epic-Datei existierte bislang nicht — reine Nachdokumentation der bereits getroffenen Architektur-Entscheidung, damit sie im Backlog nicht verloren geht, bis ein konkreter Bedarf zur Umsetzung führt.

Referenzen

Alte Arbeitskarte (übernommen, Karten-Datei gelöscht): Karte 13 Hauptserver mit Satelliten-Servern. Weiterhin gültige Detail-Referenz (nicht gelöscht, eigenständiges Prompt-Ergebnisdokument): ergebnisse/17_mobile_offline.md Abschnitt 7, ergebnisse/20_datenbank_schema.md Punkt 10.

Reference in New Issue View Git Blame Copy Permalink