Support ScheduledTask control and persistent logs

Dokumentation.md

@@ -1,6 +1,6 @@
 # BizTalk Platform Management Tool Dokumentation
 
-**Stand:** 2026-08-19
+**Stand:** 2026-08-26
 **Implementierung:** C# WinForms, .NET Framework 4.6.1
 **Archivierte PowerShell-Version:** `archive/powershell/BizTalkPlatformManagementTool.ps1`
 
@@ -20,6 +20,8 @@ Das BizTalk Platform Management Tool unterstützt kontrollierte Wartungsfenster
 - Projekt: `src/BizTalkPlatformManagementTool/BizTalkPlatformManagementTool.csproj`
 - UI: `src/BizTalkPlatformManagementTool/Ui/MainForm.cs`
 - WMI-Zugriff: `src/BizTalkPlatformManagementTool/Services/BizTalkWmiClient.cs`
+- Adapter-Assemblyauflösung: `src/BizTalkPlatformManagementTool/Services/AdapterAssemblyResolver.cs`
+- Persistentes Laufzeitlogging: `src/BizTalkPlatformManagementTool/Services/OperationLogger.cs`
 - Operationslogik: `src/BizTalkPlatformManagementTool/Services/BizTalkOperationService.cs`
 - Snapshot-Validierung: `src/BizTalkPlatformManagementTool/Services/SnapshotValidator.cs`
 - Installer: `src/BizTalkPlatformManagementTool.Setup`
@@ -58,7 +60,7 @@ Selbsterklärende Zuweisungen und reine UI-Konstruktion werden nicht zeilenweise
 
 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.
 
-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.
+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. Beim nächsten Start wird die aufbewahrte Historie erneut geladen. **Log Folder** öffnet den lokalen Ablageordner, **Close** beendet die Anwendung.
 
 ## Sicherheitsdesign
 
@@ -67,7 +69,8 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
 - 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.
 - Jede Operation schreibt Einträge in das sichtbare Operation Log.
 - Zusätzlich wird unter `%ProgramData%\BizTalkPlatformManagementTool\Logs` eine tägliche Logdatei `BizTalkPlatformManagementTool-yyyy-MM-dd.log` geschrieben. Nur wenn ProgramData nicht verfügbar ist, wird auf das EXE-Verzeichnis zurückgefallen.
-- Logdateien werden rollierend für den aktuellen Tag plus vier vorherige Tage vorgehalten.
+- Der aktuelle Tag bleibt als `.log` lesbar. Abgeschlossene Vortage werden als `.log.gz` komprimiert; aktueller Tag plus 29 Vortage bleiben erhalten.
+- Beim Programmstart werden bis zu 10.000 der neuesten Einträge aus `.log` und `.log.gz` chronologisch in das Operation Log geladen.
 - 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.
@@ -78,6 +81,7 @@ Die Statusanzeige rechts im Kopfbereich bewertet die Host-Instance-Zustaende des
 - Wartezeiten nutzen konfigurierbare Timeout- und Polling-Werte.
 - Host Instances auf anderen Servern werden übersprungen und als Warnung protokolliert.
 - Echte Shutdown-/Restore-Schritte protokollieren WMI-Klasse, Schlüssel, Zielobjekt und Methode, damit Fehler wie WMI-Query- oder Methodenfehler eindeutig zugeordnet werden können.
+- Fehler protokollieren Typ, HRESULT, vollständige innere Exception-Kette, vorhandenes Fusion-Loaderprotokoll und Stacktrace identisch im Grid, Ergebnisreport und Laufzeitlog.
 - Restore-Pläne werden abgelehnt, wenn Snapshot-Server und ausgewählter Zielserver nicht übereinstimmen; Kurzname und FQDN desselben Hosts gelten als identisch.
 - Pro Windows-Sitzung ist nur eine Toolinstanz zulässig; das Fenster kann während einer aktiven WMI-Operation nicht geschlossen werden.
 - Die EXE enthält zusätzlich einen WMI-freien `--self-test`, den der Installer vor und nach der Aktivierung ausführt.
@@ -120,6 +124,18 @@ Der Best-effort-Ansatz bedeutet nicht, dass Fehler ignoriert werden: Jeder Teilf
 - Orchestrations mit Status `Bound` bleiben unverändert und werden zur manuellen Prüfung markiert, weil ein blindes Unenlist zu `Unbound` führen kann.
 - Receive Locations werden zuletzt aktiviert, damit eingehender Verkehr erst nach Host Instances und abhängigen Artefakten wieder aufgenommen wird.
 
+## ScheduledTask-Adapter
+
+Beim Fremdadapter `Schedule`/ScheduledTask 7.0.2 wird `MSBTS_ReceiveLocation.Enable` beziehungsweise `.Disable` erst ausgeführt, nachdem die für die Transportdatenvalidierung erforderliche `Microsoft.BizTalk.Scheduler.dll` prozesslokal geladen werden konnte. Die Planzeile enthält dafür Adaptername und `scheduler:`-Adresse aus dem Snapshot.
+
+Der Resolver sucht nur in vorhandenen, vertrauenswürdigen Installationsverzeichnissen und akzeptiert eine DLL erst nach Prüfung der Assemblyidentität. Er berücksichtigt:
+
+1. `AdapterAssemblySearchPaths` aus der EXE-Konfiguration,
+2. Installations- und Assemblypfade aus beiden BizTalk-Registryansichten,
+3. lokale Verzeichnisse `Microsoft BizTalk Server*` und `BizTalk ScheduledTask Adapter*` unter Program Files (x86).
+
+Die Standardkonfiguration enthält BizTalk Server 2020 und den im PROD-Screenshot bestätigten Pfad `C:\Program Files (x86)\BizTalk ScheduledTask Adapter 7.0.2`. Die Auflösung gilt nur im Toolprozess. Es werden weder GAC noch Adapterdateien verändert. Ist die erforderliche Assembly nicht auffindbar oder nicht zur angeforderten Identität passend, scheitert nur dieser Schritt mit vollständiger Pfad-, Versions- und Loaderdiagnose; der Executor arbeitet die restlichen unabhängigen Schritte weiter ab.
+
 ## Ausgabedateien
 
 - Snapshots: `before.json`, `after.json`
@@ -129,13 +145,15 @@ Der Best-effort-Ansatz bedeutet nicht, dass Fehler ignoriert werden: Jeder Teilf
 - 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`
+- Laufzeitlogs: `%ProgramData%\BizTalkPlatformManagementTool\Logs\BizTalkPlatformManagementTool-yyyy-MM-dd.log` und komprimierte Vortage `*.log.gz`
 - Installerlogs: `%ProgramData%\BizTalkPlatformManagementTool\InstallerLogs\setup-*.log`
 
 ## Fehleranalyse
 
 Bei echten Shutdown- und Restore-Aktionen wird jeder Schritt vor der Ausführung mit Artefakttyp, WMI-Klasse, Schlüsselproperty, Schlüsselwert und Methodenname protokolliert. Die Objektauflösung verwendet eine breite `SELECT * FROM <class>`-Abfrage und filtert danach im Prozess auf den Schlüsselwert. Dadurch können Host-Instance-Namen und andere BizTalk-Namen mit Sonderzeichen keine ungültige WMI-WQL-`WHERE`-Query mehr erzeugen.
 
+Bei `scheduler:` erscheinen zusätzlich `ScheduledTask adapter preflight`, alle tatsächlich verwendeten Suchverzeichnisse, Prozessbitness und bei Erfolg die vollständige geladene Assemblyidentität samt Pfad. Ein Ladefehler enthält die anfordernde Assembly, HRESULT, Fusion-Details und Stacktrace. Für eine Supportanalyse sind die Tagesdatei, relevante `.log.gz`, der passende `*-result.json`, Plan, Vorher-/Nachher-Snapshot und die unveränderte EXE-Konfiguration zu sichern.
+
 Snapshot- und Plan-JSON-Dateien werden als UTF-8 ohne BOM über eine temporäre Datei im Zielverzeichnis und anschließenden atomaren Austausch geschrieben. Beim Laden werden vorhandene Dateien mit UTF-8-BOM oder durch Encoding-Konvertierung sichtbar gewordenem BOM-Marker toleriert. Deserialisierte Snapshots werden normalisiert und auf leere Namen, Duplikate und fehlende Strukturen geprüft.
 
 Diffs verwenden den zusammengesetzten Schlüssel aus Anwendung und Artefaktname. Gleichnamige Artefakte in verschiedenen BizTalk-Anwendungen überschreiben sich daher nicht mehr. CSV-Werte mit Präfix `=`, `+`, `-`, `@` oder Tab werden mit einem Apostroph neutralisiert, damit Tabellenkalkulationen sie nicht als Formel ausführen.