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
docs/PROD-ScheduledTask-und-Laufzeitlogging-2026-08-26.md
+8 -7
View File
@@ -2,7 +2,7 @@
**Stand:** 2026-08-26
**Zielversion:** 2.3.1
**Zielversion:** 2.3.2
**Betroffener Adapter:** BizTalk ScheduledTask Adapter 7.0.2
@@ -17,8 +17,8 @@ Version 2.3.1 erkennt ScheduledTask-Schritte an Adaptername oder `scheduler:`-UR
## Vorbereitung
1. Vorhandene `before.json`, Ergebnisdateien und Laufzeitlogs außerhalb des Installationsordners sichern.
2. Setup 2.3.1 als Administrator installieren beziehungsweise aktualisieren.
3. Im Setup-Log `setup_version=2.3.1.0` und erfolgreichen Ziel-Self-Test prüfen.
2. Setup 2.3.2 als Administrator installieren beziehungsweise aktualisieren.
3. Im Setup-Log `setup_version=2.3.2.0` und erfolgreichen Ziel-Self-Test prüfen.
4. Tool als Administrator starten, den grünen Eintrag `Runtime log storage verified by startup append` prüfen und mit **Log Folder** den dort genannten aktiven Pfad öffnen. Normalfall ist `%ProgramData%\BizTalkPlatformManagementTool\Logs`.
5. Prüfen, dass der lokale BizTalk-Installationsordner `Microsoft.BizTalk.Scheduler.dll` enthält.
6. Nur wenn BizTalk oder der Adapter abweichend installiert wurde: `AdapterAssemblySearchPaths` in `BizTalkPlatformManagementTool.exe.config` um den vorhandenen lokalen Ordner ergänzen. Mehrere Pfade werden mit Semikolon getrennt. Keine DLL aus ACC, einer alten BizTalk-Version oder einem Downloadordner kopieren.
@@ -37,9 +37,10 @@ Version 2.3.1 erkennt ScheduledTask-Schritte an Adaptername oder `scheduler:`-UR
- `Calling MSBTS_ReceiveLocation.Disable`
- `Reached: Disable receive location completed`
7. In `shutdown-result.json` muss der Schritt `Succeeded` oder bei bereits erreichtem Zustand `AlreadySatisfied` sein.
8. Nach der Wartung **Restore** zunächst im Dry-run, danach real ausführen.
9. Entsprechend `Calling MSBTS_ReceiveLocation.Enable`, den erreichten Zustand und `Succeeded`/`AlreadySatisfied` prüfen.
10. **Snapshot After** und **Compare** ausführen; die Receive Location muss dem gespeicherten Sollzustand entsprechen.
8. Am Drain-Checkpoint Receive-Location-Ergebnisse prüfen, Group Hub/Monitoring leer laufen lassen und erst dann **Yes** wählen.
9. Nach der Wartung **Restore** zunächst im Dry-run, danach real ausführen.
10. Entsprechend `Calling MSBTS_ReceiveLocation.Enable`, den erreichten Zustand und `Succeeded`/`AlreadySatisfied` prüfen.
11. **Snapshot After** und **Compare** ausführen; die Receive Location muss dem gespeicherten Sollzustand entsprechen.
## Logging-Test über Neustart
@@ -77,6 +78,6 @@ Der Fehlerdatensatz enthält Exceptiontyp, HRESULT, innere Ausnahmen, vorhandene
- Ergebnisreport und Nachher-Snapshot werden auch bei einem Teilfehler soweit möglich geschrieben.
- Historisches Log erscheint nach Neustart wieder im Grid.
- Vortagslogs werden komprimiert und exakt 30 Kalendertage aufbewahrt.
- Setup, Tool und Ergebnisdateien melden Version 2.3.1 beziehungsweise `2.3.1-net461`.
- Setup, Tool und Ergebnisdateien melden Version 2.3.2 beziehungsweise `2.3.2-net461`.
Die lokale Mono-Toolchain prüft Resolverlogik, Identitätsgrenze, Persistenz, Kompression und Aufbewahrung ohne BizTalk. Die endgültige Freigabe erfordert diesen realen Windows-/BizTalk-/PROD-Test.