4. Lösungsstrategie

Alle vier Vernetzungsarten laufen über eine Pipeline und unterscheiden sich nur im Sync-Profil, das festlegt, welche Daten welchen Partner mit welchen Rechten erreichen.

Kernideen

Hinweis

aus den Funktionale Anforderungen und Querschnittsanforderungen von PM

Quality Ziel	Ansatz	ADR
Vertraulichkeit	Deny-by-default; Getrennter Partner Account im Broker mit Subject-Berechtigungen; Creds mit Expiry
Zuverlässigkeit	JetStream-Persistenz, explizites Ack, Snapshot + LSN-Catch-up, Tombstones, Retry + Backoff
Throughput und Priorisierung (QoS)	Leaf-Verbindungen mit Source Streams; Prioritätsklassen mit getrennten Streams; Blobs on demand	⚠️Prioklassen
Konsistenz	Feldweises LWW auf Basis von Änderungszeitstempeln je Feld; Konfliktprotokoll an Betroffene	⚠️Feldweise LWW
Nachvollziehbarkeit	Append-only-Audit mit knotenübergreifender Korrelations-ID; Spiegelung relevanter Ereignisse ins Einsatztagebuch
Betreibbarkeit	HUB-DB als Source of Truth, Reconcile-Loop rendert NATS-Konfiguration; Hub per docker compose

Sync-Profile je Vernetzungsart

Ein Sync-Profil ist die einheitliche Abstraktion über UC1-UC4. Eine Kopplung (Partnerbeziehung) trägt ein Profil, ein Share ist die konkrete Freigabe eines Datenumfangs.

Sync-Profil	Kopplung	Share-Umfang (Scope)	Stammdaten	Lebendsdauer	Share Annahme
INSTANCE (UC1)	dauerhaft, SysAdmin beidseitig bestätigt	Instanz (alle Einsätze)	ja, außer lokale Bereiche	bis zur Auflösung	implizit durch Kopplung
DEPARTMENT (UC2)	dauerhaft, SysAdmin	Befehlsstelle(n); optional nur aktive Einsätze	nur zugehörige	bis zur Auflösung	implizit
ADHOC (UC3)	temporär, durch Einladung	ein Einsatz (optional Abschnitt)	nein	bis Teilen beendet / Einsatz beendet	immer explizit
FEDERATED (UC4)	dauerhaft, SysAdmin; Verbindung überwacht	ein Einsatz je Share	nein	bis Teilen beendet	konfigurierbar (B-015)

Anmerkungen

Um die Vernetzungsarten UC3 und UC4 umzusetzen, müssen in CX5 Einsätze, sowie deren Missions-Resourcen und andere missionsbezogene Daten unabhängig voneinander arbeiten. Zum Beispiel erwartet CX5 aktuell für jede Meldung die in einer Mission geschrieben wird, das die Meldungsart mit dieser bestimmten ID in den Stammdaten angelegt und konfiguriert ist. Diese Meldungsarten werden jedoch je Instanz gepflegt und sollen nicht übertragen und in der anderen Instanz erscheinen. Ein solche Übertragung der Stammdaten würde ansonsten zu doppelt benannte Meldungsarten mit unterschiedlichen Konfigurationen führen können, oder bei Verknüpfung der gleichbenannten Meldungsarten, zu einer Unterschiedlichen und somit inkonsistenten Verarbeitung der Meldungen.

UC1: Instance Sync

Für UC1 bestehen keine Einschränkungen und alle Daten können Synchronisiert werden. Hier müsste nur auf ein Snapshotting für neue Nodes im Sync, sowie Catchup für lange inaktive Nodes geachtet werden.

UC2: Department Sync

Für UC2 besteht zu Punkten aus UC1 zusätzlich die Einschränkung auf Departments. Missions- sowie Stammdaten müssen hier bei der Synchronisierung zu Befehlsstellen zugeordnet, gefiltert und anschließend übertragen werden.

UC3: Adhoc Sync

Für UC3 muss CX5 mit asynchronem Stammdatensatz und Unterschieden in Missionen zurechtkommen, dort besteht die Einschränkung auf keine Stammdaten und nur bestimmte Missionsdaten. (Eine vorerst vereinfachte Variante wäre die möglichkeit Missions-Ids zu verbinden, feste Empfängergruppen für externe Systeme zu erstellen und diese wie Email-Eingang zwischen den Systemen zu behandlen. Jedoch sind die Anforderungen weit mehr als eine einfache Meldungskommunikation)

UC4: Federated Sync

Für UC4 besteht gegenüber UC3 keine weiteren Einschränkungen, der Unterschied liegt in der Verwaltung der Verbindung von Adhoc zu Dauerverbindung.

Kombination von Vernetzungsarten

Datenhoheit bei Mischform ist fachlich offen (A-002),
Bis dahin: Nimmt ein NOde im UC1/2 Sync eine Mission per Adhoc-Share an bleibt diese auf dem Node.

Versionshandling

Gekoppelte Instanzen laufen nicht zwingend auf derselben CX5-Version. Damit trotzdem synchronisiert werden kann, wird die Kompatibilität je Modul und nicht je Gesamtversion bewertet (A-010).

Schema als Code: Analog zu EF-Migrationen werden die Avro-Schemata der synchronisierten Tabellen im CX5-Source gepflegt, zusammen mit der Tabellenklassifizierung (Tabelle → Modul). Jede Schemaänderung ist damit Teil des Releases, versioniert und reviewbar.

Ablauf:

1. Hub.Schema liest beim Start die Schemata und Klassifizierung der lokalen Instanz und bildet je Modul einen Fingerprint.
2. Beim Koppeln bzw. Annehmen eines Shares tauschen die HUBs ihre Modul-Schemata aus.
3. Hub.Schema prüft je Modul die Avro-Kompatibilität in beide Richtungen (eigenes Schema liest Partner-Schema und umgekehrt).
4. Kompatible Module werden synchronisiert; Unterschiede gleicht die Avro Schema Resolution beim Lesen aus (Up-/Down-Kompatibilität).
5. Inkompatible Module werden für diese Kopplung nicht synchronisiert. Beide Partner erhalten einen Hinweis mit den betroffenen Modulen, alle anderen Module laufen weiter.
6. Nach einem Update eines Partners wird die Prüfung erneut ausgeführt; der Modulstatus kann sich dadurch in beide Richtungen ändern.

Beispiel: Instanz A hat in der Checkliste eine Spalte im Typ geändert, Instanz B noch nicht. Das Modul Checklisten wird zwischen A und B ausgesetzt und bei beiden als inkompatibel angezeigt, Meldungen, Kräfte usw. werden weiter synchronisiert.

Änderung am Schema	Bewertung	Behandlung
Neues Feld mit Default	kompatibel	ältere Partner ignorieren das Feld, neuere setzen den Default
Feld entfernt, das einen Default hatte	kompatibel	ältere Partner setzen den Default
Typerweiterung (z. B. int → long)	nur aufwärts kompatibel	Modul nur in eine Richtung lesbar, gilt für Sync als inkompatibel
Umbenennung mit Avro-aliases	kompatibel	Zuordnung über Alias
Umbenennung ohne Alias, Typänderung, neues Pflichtfeld ohne Default, geänderter Schlüssel	inkompatibel	Modul wird ausgesetzt, Hinweis an beide Partner

Anmerkungen:

• Für Sync-relevante Tabellen gilt Avro-Kompatibilität FULL (vor- und rückwärts). Ein Build-Check prüft neue Schemata gegen die der bisher ausgelieferten Versionen, sodass Breaking Changes bewusst entschieden werden statt unbemerkt ins Release zu gelangen.
• Jede Nachricht trägt die Schema-ID bzw. den Fingerprint des Senders im Header, damit der Empfänger das passende Writer-Schema zur Resolution nutzt.
• Avro-Defaults dürfen beim Anwenden keine echten Werte überschreiben. Ein älterer Partner kennt ein neues Feld nicht, sein Update darf das Feld beim Empfänger daher nicht auf den Default zurücksetzen. Angewendet werden nur Felder, die im Writer-Schema enthalten sind (passt zum feldweisen LWW, A-003).
• Avro prüft nur die Struktur. Semantische Änderungen (z. B. neue Bedeutung eines Enum-Werts oder Status) erkennt die Prüfung nicht und müssen als Breaking Change behandelt werden.

Auslieferungsstufen

• v0.1 - Kernfunktionen
  • gehärtete Pipeline (DB → CDC → NATS → HUB → NATS → Partner)
  • Fest konfigurierbare mit Sync Profil INSTANCE
  • HUB Protokoll v1 (Partner ↔ Partner)
  • Validierung Avro/Schema-Registry
  • Sync von Daten ohne Blobs
  • Dashboard und einfache Metriken
• v0.1+1
  • A-003: Feldweise LWW
  • Versionsaushandlung auf Modul-Ebene per Schema Abgleich
• v0.2 - Kopplung
  • Trust / Enrollment
  • Profile DEPARTMENT, FEDERATED, ADHOC
    Aktuell bereits bekannter Blocker für weitere Profile in v0.2 ist das Verknüpfte Stammdaten-Handling in CX5 Missionen.
  • Erweiterung HUB Protokoll (Partner ↔ Partner)
  • (optional) mDNS Discovery
• v0.3 - Erweiterung
  • Blobs/Anhänge
  • A-011: Übernahme alter Master/Client Konfiguration

Annahme: Die Reihenfolge ist ein Vorschlag und muss noch abgestimmt werden