mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
afad3c5a02
meldestelle/docs/99_Journal/2026-04-16_ZNS-First-Wizard-Strategy.md
Stefan Mogeritsch 3b7abc55a4 feat(zns-import): DAT-Dateisupport hinzugefügt, Fehlerbehebung und UI-Anpassungen 
Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-16 16:12:53 +02:00

3.8 KiB
Raw Blame History

Journal-Eintrag: 2026-04-16 - ZNS-First Wizard & ZNS-Light Strategie

🏗️ [Lead Architect] & 👷 [Backend Developer] & 🖌️ [UI/UX Designer]

🎯 Zielsetzung

Lösung des Henne-Ei-Problems bei der Veranstaltungs-Anlage durch Invertierung des Workflows. Sicherstellung einer hohen Performance (Speed over Animation) durch selektiven ZNS-Import.

🛠️ Getroffene Entscheidungen

1. Der "ZNS-First Enrollment" Workflow (3-Schritt-Wizard)

Der Wizard für eine neue Veranstaltung wird radikal umgebaut, um die Datenintegrität von Anfang an sicherzustellen:

  • Schritt 1: ZNS-Basis & Veranstalter
    • Upload der ZNS.zip.
    • Sofortiger Import der VEREIN01.dat (Vereine) und LIZENZ01.dat (Personen).
    • Auswahl des Veranstalters aus den importierten Daten (oder manuelle Neuanlage).
  • Schritt 2: Meta-Daten & DB-Initialisierung
    • Eingabe von Titel, Datum (von-bis) und Ort.
    • Nach Validierung: Generierung der veranstaltungId (UUID).
    • Provisionierung der spezifischen Veranstaltungs-Datenbank und Transfer der ZNS-Light-Daten aus dem Staging-Buffer.
  • Schritt 3: Fachlicher Typ
    • Wahl der Veranstaltungsart (derzeit "Turnier").
    • Weiterleitung zum Turnier-Cockpit.

2. "ZNS-Light" Performance-Strategie

Um die Wartezeit beim ersten Import von ~20 Minuten auf wenige Sekunden/Minuten zu reduzieren:

  • Light-Modus: Nur VEREIN01 und LIZENZ01 werden im Wizard geladen.
  • Lazy-Modus: Die massiven Datenmengen von PFERDE01 und RICHT01 werden erst im Turnier-Setup oder bei Bedarf im Hintergrund geladen.

3. Frontend-Konsolidierung (Single Source of Truth)

  • Alle Entwürfe (V1/V2) werden im VeranstaltungNeuScreen.kt zusammengeführt.
  • Redundante Screens wie der separate StammdatenImportScreen werden als Komponente in den Wizard integriert.

🚀 Nächste Schritte (für die neue Session)

  1. Backend-Staging-Buffer: Implementierung der temporären Speicherung der ZNS-Light-Daten während des Wizards.
  2. Wizard-Implementation: Umsetzung des 3-Schritt-Flows im VeranstaltungNeuScreen.kt.
  3. API-Erweiterung: ZnsImportService um den mode=LIGHT Parameter erweitern.

🧹 [Curator]: Journal-Eintrag für Session am 16. April 2026 abgeschlossen.

  • Status: Implementierung des ZNS-First Wizards in VeranstaltungKonfigV2 abgeschlossen.
  • Resultat: Performance-Steigerung durch ZNS-Light Integration direkt im ersten Wizard-Schritt.
  • Technik: Entkopplung via ZnsImportProvider Interface erfolgreich angewendet.

🧹 [Curator]: Dieses Dokument wurde um die finalen Implementierungsdetails ergänzt. Alle fachlichen und technischen Parameter sind hiermit fixiert und umgesetzt.

Nachtrag: 2026-04-16 15:00 - Actuator-Fix (Docker-Stability)

  • Problem: ZNS-Import-Service meldete 404 auf /actuator/health/readiness unter Docker-Compose, was zu ungesunden Containern führte.
  • Lösung: Explizite Aktivierung der probes in der application.yaml ( management.endpoint.health.probes.enabled: true).
  • Optimierung: Healthcheck in dc-backend.yaml auf wget --no-verbose umgestellt für bessere Diagnosemöglichkeiten.

Nachtrag: 2026-04-16 15:30 - Connectivity & Serialization Fixes

  • Connectivity: ConnectivityTracker wurde auf den korrekten Health-Pfad /api/ping/health umgestellt. Der Footer zeigt nun korrekt den Online-Status ("Cloud synchronisiert") an.
  • Serialization: Behebung des Fehlers Serializer for class 'JobIdResponse' is not found. Die DTO-Klasse wurde im Frontend in ImportStartResponse umbenannt (passend zum Backend) und die Sichtbarkeit auf public erhöht.
  • Flexibilität: Der ZNS-Importer unterstützt nun sowohl .zip als auch .dat Dateien (z.B. direkte VEREIN01.dat). Die UI (pickZnsFile) und das ViewModel wurden entsprechend erweitert.