33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
# ADR-0023: ZNS-First Enrollment Pattern (ZNS-Light)
|
|
|
|
## Status
|
|
|
|
Akzeptiert
|
|
|
|
## Kontext
|
|
|
|
Die Anlage einer neuen pferdesportlichen Veranstaltung erfordert eine solide Datenbasis (ZNS-Daten für Vereine, Reiter,
|
|
Pferde etc.). Der bisherige Ansatz (erst Veranstaltung anlegen, dann Daten importieren) führte zu Konsistenz-Problemen,
|
|
da der Veranstalter (Verein) oft bereits im ZNS-Stamm existiert.
|
|
Darüber hinaus dauert ein vollständiger ZNS-Import aufgrund der Datenmenge (~20 Minuten) zu lange, um ihn in einen
|
|
Echtzeit-Wizard einzubauen.
|
|
|
|
## Entscheidung
|
|
|
|
Wir führen das **ZNS-First Enrollment Pattern** ein:
|
|
|
|
1. Der Wizard beginnt mit dem Import der ZNS-Daten.
|
|
2. Um Performance sicherzustellen, wird im ersten Schritt ein **"ZNS-Light" Import** durchgeführt (nur `VEREIN01.dat`
|
|
und `LIZENZ01.dat`).
|
|
3. Die importierten Daten werden in einer **Staging-Area (Backend-Buffer)** temporär vorgehalten.
|
|
4. Erst bei der Finalisierung der Veranstaltungs-Metadaten wird die UUID generiert und die mandantenfähige Datenbank
|
|
provisioniert.
|
|
5. Massive Datensätze (Pferde, Richter) werden **lazy** nachgeladen.
|
|
|
|
## Konsequenzen
|
|
|
|
* **Positiv:** Höhere Datenqualität (Veranstalter wird sofort korrekt gematcht).
|
|
* **Positiv:** Minimale Wartezeit im Wizard durch selektiven Import.
|
|
* **Negativ:** Backend muss Staging-Funktionalität für unfertige Wizards bereitstellen.
|
|
* **Frontend:** Der `VeranstaltungNeuScreen` wird zum zentralen Orchestrator dieses 3-Schritt-Flows.
|