meldestelle/docs/99_Journal/2026-04-16_ZNS-First-Wizard-Strategy.md
2026-04-16 16:12:53 +02:00

74 lines
3.8 KiB
Markdown

# 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.