Fix BizTalk application ownership mapping
This commit is contained in:
@@ -0,0 +1,81 @@
|
||||
# PROD-Analyse: `(Unknown Application)` bei Runtime-Artefakten
|
||||
|
||||
**Stand:** 2026-08-27
|
||||
|
||||
**Fehlerstand:** 2.3.2
|
||||
|
||||
**Zielversion:** 2.3.3
|
||||
|
||||
## Beobachtung und Bewertung
|
||||
|
||||
Im PROD-Shutdown-Plan wurden die gefundenen Send Ports mit korrekten Namen und Zuständen angezeigt, die Spalte **Application** enthielt jedoch durchgehend `(Unknown Application)`. Damit war der WMI-Zugriff selbst erfolgreich; fehlerhaft war die nachgelagerte Zuordnung der Artefakte zu BizTalk-Anwendungen.
|
||||
|
||||
Der Lauf wäre technisch weiterhin in der global sicheren Kategorie-Reihenfolge ausführbar gewesen, weil Send Ports über ihren gruppenweit eindeutigen WMI-Namen adressiert werden. Die Anzeige ist dennoch ein Produktfehler: Planreview und anwendungsbezogene Snapshot-/Diff-Auswertung benötigen die echte Ownership. Ein realer Lauf mit ungeklärter Zuordnung ist daher nicht freizugeben.
|
||||
|
||||
## Root Cause
|
||||
|
||||
Version 2.3.2 versuchte bei `MSBTS_SendPort`, `MSBTS_ReceiveLocation` und `MSBTS_Orchestration` Properties namens `ApplicationName`, `Application` oder `BizTalkApplication` auszulesen. Diese Properties gehören nicht zum dokumentierten Runtime-WMI-Vertrag der drei Klassen. Der Code fiel deshalb für jedes betroffene Objekt auf `(Unknown Application)` zurück.
|
||||
|
||||
Die BizTalk-Anwendung ist eine Kataloghierarchie, keine verlässliche Property dieser Runtime-WMI-Objekte. Microsoft stellt sie über `Microsoft.BizTalk.ExplorerOM` bereit: Eine Application enthält ihre Send Ports, Receive Ports samt Receive Locations und Orchestrierungen. `MSBTS_GroupSetting` liefert den Server und Namen der BizTalk Management-Datenbank, mit der `BtsCatalogExplorer` verbunden wird.
|
||||
|
||||
## Korrektur in 2.3.3
|
||||
|
||||
`BizTalkApplicationResolver` baut vor der WMI-Zustandserfassung einen read-only Index auf:
|
||||
|
||||
1. `MSBTS_GroupSetting` lesen und genau einen Management-DB-Endpunkt verlangen.
|
||||
2. Die lokal installierte `Microsoft.BizTalk.ExplorerOM.dll` über CLR/GAC oder vorhandene BizTalk-Verzeichnisse laden.
|
||||
3. Vor einem dateibasierten Fallback Simple Name und Microsoft-Public-Key-Token prüfen.
|
||||
4. Applications und deren Send Ports, Receive Ports/Locations sowie Orchestrierungen enumerieren.
|
||||
5. WMI-Artefakte case-insensitiv gegen diesen Index auflösen; bei Receive Locations dient der Parent-Receive-Port als zusätzlicher Fallback.
|
||||
6. Namen, die widersprüchlich unter mehreren Anwendungen auftauchen, nicht raten, sondern weiter als unbekannt markieren.
|
||||
|
||||
Es gibt weiterhin keine Compile-time-Referenz und keine mitgelieferte Kopie der BizTalk-DLL. Der Installer-Self-Test bleibt WMI- und BizTalk-frei. ExplorerOM wird ausschließlich gelesen; Zustände, Wait-Logik und sämtliche Shutdown-/Restore-Mutationen bleiben beim bestehenden WMI-Adapter.
|
||||
|
||||
Wenn Assembly, Management-Datenbank oder Berechtigung nicht verfügbar sind, bricht die Zustandserfassung nicht verdeckt ab. Die betroffenen Zeilen bleiben sichtbar unter `(Unknown Application)`, und Grid sowie Laufzeitlog enthalten die vollständige Ursache. **Diagnose** meldet künftig sowohl die Zahl sichtbarer Send Ports als auch die Zahl erfolgreicher Application-Zuordnungen.
|
||||
|
||||
## Lokale Verifikation
|
||||
|
||||
- Release-Rebuild aller vier .NET-Framework-4.6.1-Projekte erfolgreich.
|
||||
- 41 portable Regressionstests erfolgreich.
|
||||
- Neuer Test deckt Send Port, Receive Location, Receive-Port-Fallback, Orchestration, case-insensitive Namen und mehrdeutige Cross-Application-Namen ab.
|
||||
- WMI-freier Anwendungsselftest erfolgreich mit `2.3.3-net461`.
|
||||
- Paketmanifest, Installer-ZIP, Certutil-Base64 und SHA-256 werden durch die Release-Chain erzeugt und separat gegengeprüft.
|
||||
|
||||
Die lokale Suite kann den echten BizTalk-2020-ExplorerOM-Katalog nicht simulieren. Die abschließende Freigabe benötigt deshalb die folgende PROD-Abnahme.
|
||||
|
||||
## PROD-Abnahme nach dem Update
|
||||
|
||||
1. Setup 2.3.3 als Administrator ausführen und im Setup-Log `setup_version=2.3.3.0` sowie erfolgreichen Ziel-Self-Test prüfen.
|
||||
2. Tool starten, PROD-Zielserver kontrollieren und **Dry run** aktiviert lassen.
|
||||
3. **Diagnose** ausführen. Erwartung: `Send ports visible: N; application associations resolved: N.` mit identischen Zahlen und ohne nachfolgende Association-Warnung.
|
||||
4. Laufzeitlog über **Log Folder** öffnen und den Eintrag `BizTalk application catalog loaded through ExplorerOM` prüfen. Er muss plausible Zähler für Applications, Send Ports, Receive Ports/Locations und Orchestrations enthalten.
|
||||
5. **Snapshot Before** erzeugen und `before.json` prüfen:
|
||||
- keine `(Unknown Application)`-Gruppe für regulär katalogisierte Runtime-Artefakte,
|
||||
- stichprobenartig mehrere Send Ports aus unterschiedlichen Anwendungen gegen die BizTalk Administration Console abgleichen,
|
||||
- Receive Locations und Orchestrierungen ebenfalls anwendungsrichtig gruppiert.
|
||||
6. **Shutdown** nur als Dry-run ausführen. Im Grid und in `shutdown-plan.json` müssen die echten Application-Namen erscheinen; Reihenfolge und Schrittzahl gegen den Snapshot prüfen.
|
||||
7. Erst nach erfolgreichem Katalog-, Snapshot- und Dry-run-Abgleich über einen echten Wartungslauf entscheiden.
|
||||
|
||||
## Fehlerpfad und Supportdaten
|
||||
|
||||
Sind die Diagnosezahlen unterschiedlich oder erscheinen weiterhin unbekannte Anwendungen, keinen echten Shutdown starten. Sichern:
|
||||
|
||||
- aktuelle Tageslogdatei,
|
||||
- Diagnose-Screenshot,
|
||||
- `before.json` und Sidecars,
|
||||
- `shutdown-plan.json` aus dem Dry-run,
|
||||
- Setup-Log,
|
||||
- genaue Windows-Identität des Toolprozesses,
|
||||
- WMI-/ExplorerOM-/SQL-Exception einschließlich HRESULT und Inner Exceptions.
|
||||
|
||||
Dann insbesondere prüfen: lokale BizTalk-Administrationskomponenten/ExplorerOM-Installation, Erreichbarkeit der in `MSBTS_GroupSetting` gemeldeten Management-Datenbank und Leseberechtigung des ausführenden Kontos.
|
||||
|
||||
## Microsoft-Quellen
|
||||
|
||||
- [MSBTS_SendPort (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-sendport-wmi)
|
||||
- [MSBTS_ReceiveLocation (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-receivelocation-wmi)
|
||||
- [MSBTS_Orchestration (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-orchestration-wmi)
|
||||
- [MSBTS_GroupSetting (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-groupsetting-wmi)
|
||||
- [BtsCatalogExplorer (ExplorerOM)](https://learn.microsoft.com/en-us/dotnet/api/microsoft.biztalk.explorerom.btscatalogexplorer?view=bts-2020)
|
||||
- [Application (ExplorerOM)](https://learn.microsoft.com/en-us/dotnet/api/microsoft.biztalk.explorerom.application?view=bts-2020)
|
||||
- [BtsOrchestration (ExplorerOM)](https://learn.microsoft.com/en-us/dotnet/api/microsoft.biztalk.explorerom.btsorchestration?view=bts-2020)
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Stand:** 2026-08-26
|
||||
|
||||
**Zielversion:** 2.3.2
|
||||
**Zielversion:** 2.3.3
|
||||
|
||||
**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.2 als Administrator installieren beziehungsweise aktualisieren.
|
||||
3. Im Setup-Log `setup_version=2.3.2.0` und erfolgreichen Ziel-Self-Test prüfen.
|
||||
2. Setup 2.3.3 als Administrator installieren beziehungsweise aktualisieren.
|
||||
3. Im Setup-Log `setup_version=2.3.3.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.
|
||||
@@ -78,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.2 beziehungsweise `2.3.2-net461`.
|
||||
- Setup, Tool und Ergebnisdateien melden Version 2.3.3 beziehungsweise `2.3.3-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.
|
||||
|
||||
Reference in New Issue
Block a user