Add resilient emergency restore for partial BizTalk operations

Dokumentation.md

@@ -1,6 +1,6 @@
 # BizTalk Platform Management Tool Dokumentation
 
-**Stand:** 2026-08-11
+**Stand:** 2026-08-19
 **Implementierung:** C# WinForms, .NET Framework 4.6.1
 **Archivierte PowerShell-Version:** `archive/powershell/BizTalkPlatformManagementTool.ps1`
 
@@ -56,6 +56,8 @@ Selbsterklärende Zuweisungen und reine UI-Konstruktion werden nicht zeilenweise
 9. Nach der Wartung mit **Restore** aus `before.json` wiederherstellen.
 10. 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. 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.
+
 Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des letzten Snapshots und zeigt `Started`, `Stopped`, `Partial` oder `Unknown`. **Clear** leert die sichtbaren Ergebnis- und Log-Grids, loescht aber keine Dateien. **Close** beendet die Anwendung.
 
 ## Sicherheitsdesign
@@ -68,6 +70,10 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
 - Logdateien werden rollierend für den aktuellen Tag plus vier vorherige Tage vorgehalten.
 - Der Kopfbereich zeigt den zuletzt erkannten Umgebungsstatus aus den Host Instances.
 - Operationspläne werden vor Laufzeitänderungen gespeichert.
+- Jeder ausführbare Schritt prüft vor der Mutation, ob sein Sollzustand bereits erreicht ist.
+- Ein Einzelfehler stoppt nicht mehr die restlichen unabhängigen Schritte; alle Ergebnisse werden einzeln persistiert.
+- Ein Teilfehler bleibt im GUI und im Ergebnisreport ausdrücklich fehlgeschlagen und wird nicht als Gesamterfolg ausgegeben.
+- Der Nachher-Snapshot wird auch nach Einzelfehlern separat versucht; ein Snapshotfehler wird im Ergebnisreport gesichert.
 - WMI-Methodenrückgaben werden geprüft.
 - Wartezeiten nutzen konfigurierbare Timeout- und Polling-Werte.
 - Host Instances auf anderen Servern werden übersprungen und als Warnung protokolliert.
@@ -90,6 +96,22 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
 3. Orchestrations wiederherstellen, soweit dies sicher möglich ist.
 4. Receive Locations zuletzt wiederherstellen.
 
+Die Kategorienreihenfolge gilt global über alle BizTalk-Anwendungen. Dadurch wird keine Receive Location einer alphabetisch früheren Anwendung aktiviert, bevor Send Ports und Orchestrations späterer Anwendungen behandelt wurden.
+
+## Emergency Restore
+
+Der Emergency Restore benötigt nur eine valide `before.json` und denselben Zielserver. Er erzeugt keine neue Vorheraufnahme und überschreibt die Recovery-Quelle nicht.
+
+1. Timestamp-basierte Kopie der Eingabedatei sichern.
+2. Enterprise Single Sign-On (`ENTSSO`) auf dem Zielserver auf `Running` bringen.
+3. Zuvor gestartete Host Instances zustandsbewusst starten.
+4. Send Ports, Orchestrations und Receive Locations in global sicherer Reihenfolge auf den Snapshotzustand abgleichen.
+5. Bereits korrekte Zustände als `AlreadySatisfied` überspringen.
+6. Isolierte WMI-/Adapterfehler als `Failed` erfassen und mit dem nächsten unabhängigen Schritt fortfahren.
+7. Nachher-Snapshot unabhängig versuchen und vollständigen Ergebnisreport schreiben.
+
+Der Best-effort-Ansatz bedeutet nicht, dass Fehler ignoriert werden: Jeder Teilfehler erzeugt einen roten/fehlgeschlagenen Abschluss und erfordert die Prüfung des Ergebnisreports. Er verhindert lediglich, dass beispielsweise eine einzelne nicht validierbare Receive Location alle späteren Host-, Port- oder Receive-Location-Schritte blockiert.
+
 ## Restore-Grenzen
 
 - Send Ports werden auf `Started`, `Stopped` oder `Bound` zurückgesetzt.
@@ -102,6 +124,8 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
 - Snapshots: `before.json`, `after.json`
 - Operationspläne: `shutdown-plan.json`, `restore-plan.json`
 - Nachher-Snapshots: `shutdown-after.json`, `restore-after.json`
+- Ergebnisreports: `shutdown-result.json`, `restore-result.json`
+- Emergency-Dateien: `emergency-source-before-*`, `emergency-restore-plan-*`, `emergency-restore-result-*`, `emergency-restore-after-*`
 - Diff: `diff.json`, `diff.csv`, `diff.html`
 - Snapshot-Reports: `*.csv`, `*.hosts.csv`, `*.html`
 - Laufzeitlogs: `%ProgramData%\BizTalkPlatformManagementTool\Logs\BizTalkPlatformManagementTool-yyyy-MM-dd.log`
@@ -164,6 +188,12 @@ Das äußere ZIP erhält zusätzlich eine SHA-256-Datei und eine Certutil-kompat
 - Eindeutige Fehlerphase ohne irreführende Rollbackmeldung bei einem Staging-Fehler.
 - Vollständiger Diagnosekontext mit Exception-Kette und Temp-Fallback für das Setup-Log.
 - Unabhängigkeit der Installation von Fehlern der UI-Fortschrittsanzeige.
+- Fortsetzung nach einer simulierten `Microsoft.BizTalk.Scheduler`-Exception.
+- Idempotentes Überspringen bereits erreichter Sollzustände.
+- `ENTSSO` als erster Emergency-Restore-Schritt.
+- Globale Kategorie-Reihenfolge über mehrere BizTalk-Anwendungen.
+- Kurzname/FQDN-Gleichheit für Host-Instance-Schritte.
+- Persistenz vollständiger Teilfehlerreports.
 
 Der portable Build, die Tests, der Anwendungsselftest und die Paketkonsistenz sind lokal unter Mono prüfbar. Die endgültige Freigabe erfordert zusätzlich einen Windows-Test von UAC, Registry, Verknüpfungen und Setup-Rollback sowie einen repräsentativen BizTalk-2020-Test von Diagnose, Dry-run, Shutdown und Restore.