johannes/BizTalkPlatformManagementTool
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add fail-closed shutdown drain checkpoint

Browse Source
This commit is contained in:
admin
2026-08-26 12:02:37 +02:00
parent fe3c84a27f
commit b18adab26d
21 changed files with 520 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Dokumentation.md
+11 -5
View File
@@ -55,8 +55,9 @@ Selbsterklärende Zuweisungen und reine UI-Konstruktion werden nicht zeilenweise
6. Mit **Snapshot Before** die Datei `before.json` erzeugen.
7. Mit **Shutdown** den Plan `shutdown-plan.json` erzeugen und prüfen.
8. **Dry run** erst deaktivieren, wenn der Plan korrekt ist.
9. Nach der Wartung mit **Restore** aus `before.json` wiederherstellen.
10. Mit **Snapshot After** und **Compare** die Umgebung validieren.
9. Beim echten Shutdown nach den Receive Locations den Drain-Dialog geöffnet lassen, Group Hub und Enterprise-Monitoring prüfen und erst bei leer gelaufener Verarbeitung **Yes** wählen.
10. Nach der Wartung mit **Restore** aus `before.json` wiederherstellen.
11. Mit **Snapshot After** und **Compare** die Umgebung validieren.
Wenn ein echter Shutdown oder Restore nur teilweise ausgeführt wurde und lediglich die ursprüngliche `before.json` verfügbar ist, wird **Emergency Restore** verwendet. Die Quelle kann über **State...** ausgewählt und vorab über **Validate State** ohne WMI-Zugriff geprüft werden. Der Modus kopiert die Quelle unter einem timestamp-basierten Namen, überschreibt `before.json` nicht, stellt zuerst `ENTSSO` sicher und gleicht danach den gespeicherten Sollzustand zustandsbewusst ab. Der erste Lauf muss als Dry-run erfolgen.
@@ -67,6 +68,8 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
- Dry-run ist standardmäßig aktiviert.
- Beim Start wird geprüft, ob die Anwendung mit Administratorrechten läuft. Ohne erhöhte Rechte wird eine Fehlermeldung angezeigt und die Anwendung beendet.
- Echte Shutdown-/Restore-Aktionen verlangen erst nach Erzeugung und Speicherung des frischen Plans eine zusätzliche Bestätigung mit Zielserver, Plandatei und exakter Zahl ausführbarer Schritte.
- Ein echter Shutdown hält nach der globalen Receive-Location-Phase an einem im Plan gespeicherten Operator-Checkpoint. Nur ein explizites **Yes** setzt Orchestrierungen, Send Ports und Host Instances fort.
- **No** oder ein Fehler des Bestätigungsdialogs arbeitet fail-closed: spätere Planzeilen werden ohne Mutation als `NotExecuted` gespeichert; Nachher-Snapshot und Ergebnisreport werden trotzdem versucht.
- Jede Operation schreibt Einträge in das sichtbare Operation Log.
- Primär wird unter `%ProgramData%\BizTalkPlatformManagementTool\Logs` eine tägliche Logdatei `BizTalkPlatformManagementTool-yyyy-MM-dd.log` geschrieben. Jeder Kandidat muss einen echten Create/Write/Flush/Delete-Test bestehen. Die Fallbackreihenfolge ist LocalAppData, `Logs` unter dem EXE-Verzeichnis und Temp.
- Jeder GUI-Start hängt einen Prüfdatensatz an die aktive Tagesdatei an. **Log Folder** öffnet diesen tatsächlich beschreibbaren Pfad; ein Fallback oder der vollständige Ausfall des Dateiloggings wird mit Pfaden und Exception im Grid angezeigt.
@@ -90,9 +93,12 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
## Shutdown-Reihenfolge
1. Receive Locations deaktivieren, die im Snapshot aktiviert waren.
2. Orchestrations stoppen, die gestartet waren.
3. Send Ports stoppen, die gestartet waren.
4. Host Instances stoppen, die auf dem ausgewählten Server gestartet waren.
2. Operator-Checkpoint: eingehenden Verkehr, Group Hub, laufende Service Instances und Enterprise-Monitoring prüfen; erst nach dem Leerfahren fortsetzen.
3. Orchestrations stoppen, die gestartet waren.
4. Send Ports stoppen, die gestartet waren.
5. Host Instances stoppen, die auf dem ausgewählten Server gestartet waren.
`Partially Started` auf Anwendungsebene ist während der Drain-Phase erwartbar: deaktivierte Receive Locations bei noch laufenden Orchestrierungen/Send Ports entsprechen dem BizTalk-Modell „Partial Stop - Allow running instances to continue“. Das Tool setzt Anwendungen nicht zusätzlich pauschal auf `Stopped`. Ein Application-Stop ist kein reines Statusflag, sondern führt abhängig von der Auswahl weitere Mutationen bis hin zu Unenlist, Policy-Undeploy oder Instanzterminierung aus. Die artefaktgenaue Steuerung bleibt deshalb die sichere, aus `before.json` reproduzierbare Grenze.
## Restore-Reihenfolge