Kanbanize Kartenerstellung dokumentiert: Arrival-Rule-Workaround, Board-Struktur

- Neuer Abschnitt "Karten erstellen (Aufgaben-Workflow)" mit Workflow A/B - Bekannte Struktur erweitert: Workflows, Columns, Lanes für Board 1 - Pitfalls ergänzt: Arrival Rule, Parent-Link API, linkedCards read-only - Settings und Plans aktualisiert Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-05 13:09:09 +01:00
parent f0dae88639
commit 4277b10f55
21 changed files with 2636 additions and 159 deletions
--- a/plans/zesty-finding-harbor.md
+++ b/plans/zesty-finding-harbor.md
@@ -0,0 +1,188 @@
+# Plan: CRIF Nächtliche False-Positive Problemmeldungen beheben
+
+## Problem
+
+**Kanbanize-Ticket:** #13461 - "VAE-Meldungen erhält jede Nacht Nachricht über CRIF"
+
+**Symptome:**
+- Jede Nacht kommt eine Zabbix-Problemmeldung zum CRIF-Export
+- Problem löst sich nach ca. 15 Minuten automatisch
+- Die Zeiten sind sehr unregelmäßig
+
+**Betroffener Trigger:**
+- TriggerID: 44829
+- Name: `processing_backup_monitoring_hours_crif`
+- Host: SRV-JOB01
+- Kategorie: Interface/CRIF
+
+## Hintergrund
+
+Laut Dokumentation (troubleshooting.md:151-164):
+- **Ablauf:** NAV erstellt Export → Scheduled Task (02:00) lädt zu CRIF FTP hoch → Dateien werden ins Backup-Verzeichnis verschoben
+- **Trigger-Funktion:** Prüft ob Dateien jünger als 1 Tag im `\\vinos.local\sys\nav\interfaces\CRIFBuergel\backup` Ordner existieren
+- **Häufige Ursache:** NAV Aufgabenwarteschlange läuft nicht (aber hier löst sich das Problem selbst → kein echter Fehler)
+
+## Hypothese (BESTÄTIGT durch Phase 1)
+
+**VERIFIZIERTE FAKTEN:**
+- Trigger 44829 auf SRV-JOB01 überwacht CRIF-Backup (korrekt dokumentiert)
+- Item: `processing_backup_monitoring_hours_crif` (Trapper-Type, empfängt Werte)
+- Events feuern um ~01:15-01:45 CET (nicht 02:00!)
+- Scheduled Task "Transfer-FilesWinSCP" läuft um 02:00
+- **ABER:** Backup-Dateien landen schon um 01:07-01:41 (vorher!)
+
+**Erkannte Ursache:**
+Es gibt einen **ANDEREN Prozess** der die Backup-Dateien um ~01:00-01:30 erstellt (vermutlich NAV/Business Central Export). Der 02:00 Task ist nur der **Transfer**, nicht die Erstellung.
+
+Der Trigger prüft um ~01:30 und findet zu dem Zeitpunkt noch keine neuen Dateien (Export läuft noch), dann sind sie 15-45 Min später fertig → Auto-Recovery.
+
+**Problem:** Timing zwischen NAV-Export (unregelmäßig 01:07-01:41) und Monitoring-Check (~01:30) ist zu eng.
+
+## Implementierungsplan
+
+### Phase 1: Diagnose & Datensammlung ✅ ABGESCHLOSSEN
+
+**Ergebnisse:**
+
+**Trigger 44829 (verifiziert via Opus-Agent):**
+- Host: SRV-JOB01 (hostid 10636)
+- Item: 99026 "processing_backup_monitoring_hours_crif" (Trapper-Type)
+- Expression: `{86644}=1` (feuert wenn Item-Wert = 1)
+- Tags: IFS-Meldungen, VAE-Meldungen, fts
+
+**Event-Pattern (7 Tage):**
+- Häufigkeit: 5 Events in 7 Tagen (täglich nachts)
+- Timing: 01:15-01:45 CET
+- Dauer bis Recovery: 15-45 Min (Durchschnitt: 36 Min)
+- 100% Auto-Recovery
+
+**Scheduled Task "Transfer-FilesWinSCP":**
+- Läuft um: 02:00:00 täglich
+- Dauer: 2-3 Sekunden
+- LastTaskResult: 0 (erfolgreich)
+
+**KRITISCHER FUND: Timing-Diskrepanz**
+- Backup-Dateien landen: 01:07-01:41 (unregelmäßig!)
+- Scheduled Task läuft: 02:00 (zu spät!)
+- → Es gibt einen ANDEREN Prozess der die Dateien erstellt
+
+**Hypothese bestätigt:** NAV/Business Central erstellt Exports um ~01:00-01:30, Transfer-Task transportiert sie um 02:00. Trigger prüft während der Export-Erstellung läuft.
+
+### Phase 2: Lösungsansatz entwickeln
+
+**EMPFOHLENE LÖSUNG (basierend auf Phase 1):**
+
+**Option A: Monitoring-Check-Timing verschieben** ⭐ BESTE LÖSUNG
+- **Problem:** Check läuft während NAV-Export (01:15-01:45)
+- **Lösung:** Item-Update-Intervall so setzen dass Check NACH Export läuft (z.B. 02:30 oder 03:00)
+- **Vorteil:** Einfach, keine False-Positives mehr
+- **Nachteil:** Erkennt Probleme erst 1-2h später
+
+**Option B: Grace Period / Hysteresis einbauen**
+- **Problem:** Export braucht 15-45 Min aber Trigger ist ungeduldig
+- **Lösung:** Trigger feuert erst wenn 2-3 Checks in Folge fehlschlagen (z.B. "no data for 2 hours")
+- **Vorteil:** Erkennt echte Ausfälle vs. temporäre Export-Phasen
+- **Nachteil:** Komplexere Trigger-Logic
+
+**Option C: Maintenance Window**
+- **Problem:** Nächtliche Wartung/Export = False-Positive
+- **Lösung:** Maintenance Window 01:00-02:00 CET
+- **Vorteil:** Sauber, professionell
+- **Nachteil:** Echte Ausfälle in diesem Fenster werden nicht gemeldet
+
+**Option D: NAV-Export-Prozess finden und direkt überwachen**
+- **Problem:** Wir überwachen Backup-Dateien, nicht den Prozess
+- **Lösung:** NAV Aufgabenwarteschlange direkt überwachen (siehe troubleshooting.md:160 "Häufigste Ursache: NAV läuft nicht")
+- **Vorteil:** Root-Cause-Monitoring statt Symptom-Monitoring
+- **Nachteil:** Erfordert NAV-Zugriff und neue Items
+
+**EMPFEHLUNG:** Kombination A + B
+1. Check-Timing auf 02:30 verschieben (nach Export UND Transfer)
+2. Hysteresis: "Problem erst wenn 2 Checks (30 Min) fehlschlagen"
+3. Damit: False-Positives weg + echte Ausfälle erkannt
+
+### Phase 3: Fix implementieren (Option A - Check-Timing verschieben)
+
+**Ziel:** Item-Update-Intervall so setzen dass Check NACH NAV-Export + Transfer läuft.
+
+**Schritte:**
+
+1. **Item 99026 Details abrufen:**
+   - Aktuelles Update-Intervall prüfen
+   - Type = Trapper → Werte werden gepusht, kein Poll-Intervall
+   - → Das Script das die Werte pusht muss gefunden werden
+
+2. **Monitoring-Script finden:**
+   - Auf SRV-JOB01: Scheduled Task der das Item befüllt
+   - Wahrscheinlich: PowerShell-Script das Backup-Ordner prüft
+   - Task-Name vermutlich: "Zabbix*CRIF*" oder ähnlich
+   - Pfad vermutlich: `C:\Skripte\` oder `C:\Tasks\`
+
+3. **Scheduled Task anpassen:**
+   - Backup der Task-Definition erstellen
+   - Task-Zeitplan von aktuell (vermutlich 01:30) auf **02:30** verschieben
+   - Begründung: NAV-Export läuft 01:07-01:41, Transfer 02:00, Check danach um 02:30
+
+4. **Dokumentation aktualisieren:**
+   - `troubleshooting.md` Abschnitt "CRIF Bürgel Export-Monitoring" ergänzen
+   - Neues Timing dokumentieren
+   - Begründung für Änderung festhalten
+
+5. **Verifikation:**
+   - Morgen (03.02.2026) um ~02:30 Events prüfen
+   - Bestätigen: Kein False-Positive mehr
+   - 3-5 Nächte beobachten
+
+### Phase 4: Dokumentation & Abschluss
+
+1. **Troubleshooting.md aktualisieren:**
+   - Abschnitt "CRIF Bürgel Export-Monitoring" erweitern
+   - Fix und Erkenntnisse dokumentieren
+   - Pitfall hinzufügen falls relevant
+
+2. **README.md aktualisieren:**
+   - Trigger-ID Eintrag aktualisieren falls Name/Beschreibung geändert
+
+3. **Kanbanize-Kommentar erstellen:**
+   - Problemdokumentation nach Template
+   - User-Freigabe einholen bevor gepostet wird
+
+4. **Git Commit:**
+   - Dokumentationsänderungen committen
+   - Aussagekräftige Commit-Message
+
+## User-Entscheidung
+
+✅ Option A gewählt: Monitoring-Check-Timing verschieben
+- Check-Zeit von ~01:30 auf 02:30 verschieben
+- Damit läuft Check NACH NAV-Export (01:07-01:41) UND Transfer-Task (02:00)
+
+## Risiken & Überlegungen
+
+- **Kein Produktions-Impact:** CRIF-Export läuft, nur Monitoring ist zu sensitiv
+- **Vorsicht:** Schwellwert nicht zu hoch setzen, sonst übersehen wir echte Ausfälle
+- **Testing:** Idealerweise würden wir 2-3 Nächte beobachten nach dem Fix
+
+## Verification Strategy
+
+**Sofort nach Fix:**
+1. Scheduled Task Status prüfen: NextRunTime = 02:30?
+2. Task manuell triggern um zu testen
+
+**Nächste Nacht (03.02.2026):**
+1. Um ~02:35: Zabbix Events prüfen
+2. Bestätigen: Kein neues Problem-Event
+3. Bestätigen: Item-Wert = 0 (OK)
+
+**Langfristig (3-5 Nächte):**
+1. Event-Historie beobachten
+2. Bestätigen: Keine False-Positives mehr
+3. Optional: NAV-Export simuliert ausfallen lassen um zu testen ob echter Alarm käme
+
+## Success Criteria
+
+- [ ] Trigger 44829 feuert nicht mehr jede Nacht
+- [ ] Wenn CRIF-Export tatsächlich fehlt, wird er trotzdem erkannt
+- [ ] User erhält keine nächtlichen Problemmeldungen mehr
+- [ ] Dokumentation ist aktualisiert
+- [ ] Kanbanize-Kommentar erstellt und User-approved