Inventera er BizTalk-miljö innan ni räknar

En BizTalk-inventering börjar med vad som finns och vad som gick att läsa. Skriptet ger en lokal rapport med artefaktantal, källor och varningar. Använd den som startpunkt, och komplettera med flödenas beroenden innan ni uppskattar migreringsarbetet.

Hur kör jag inventeringsskriptet?

Spara filen på en maskin med BizTalks administrationsverktyg. Öppna Windows PowerShell 5.1 i filens katalog och välj var rapporten ska hamna. Granska skriptet och följ er vanliga rutin för att köra lokala skript.

.\Invoke-BizTalkInventory.ps1 -OutputPath .\biztalk-inventory.html

Det här kommandot använder den lokala WMI-källan och hämtar katalogens databasinställningar från registret. Öppna sedan HTML-filen i webbläsaren och börja med varningarna. Skriptets parametrar och beteende finns i källkoden, granskad 2026-10-03.

Kontrollera båda källornas mål om ni anger egna parametrar: -ComputerName styr bara WMI-delen. -ManagementServer och -ManagementDatabase styr katalogdelen. Ett datornamn ändrar alltså inte automatiskt vilken hanteringsdatabas som läses.

Vad beta-versionen gör

Beta-versionen räknar orkestreringar, portar och receive locations via WMI, och applikationer, pipelines, maps, schemas och BRE-policyer via BizTalks katalog-API. Sedan skriver den en lokal HTML-rapport. Den ger ännu inte komplexitetsband, beroendegraf eller spårningsanalys.

• Antal per artefakttyp som startpunkt för inventeringen.
• En källkolumn per rad, så det syns var varje siffra kommer ifrån.
• Varningar när en källa inte kan läsas, och raden markeras "ej läst" i stället för noll.
• En HTML-rapport som stannar på den lokala maskinen.

Så läser ni resultatet

Rapporten har två källor och håller isär dem. Fyra klasser läses med Get-CimInstance i namnrymden root\MicrosoftBizTalkServer: MSBTS_Orchestration, MSBTS_SendPort, MSBTS_ReceivePort och MSBTS_ReceiveLocation. Alla fyra finns i Microsofts WMI-klassreferens. Det gör däremot inte applikationer, pipelines, maps eller schemas: för dem finns ingen WMI-klass, och de räknas i stället genom Microsoft.BizTalk.ExplorerOM mot hanteringsdatabasen, tillsammans med BRE-policyerna.

Ett högt antal visar inventeringens storlek men säger inget säkert om korrelation, egen kod, EDI-avtal eller beroenden.

Varje läsfel skrivs som en varning och raden får texten "ej läst", aldrig noll. Tolka därför inte en tom miljö och en misslyckad läsning som samma sak. Det är särskilt viktigt vid fjärrkörning med -ComputerName, där behörighet och CIM-åtkomst kan skilja sig från en lokal körning.

Katalogdelen kräver att BizTalks administrationsverktyg finns på maskinen och att skriptet körs i Windows PowerShell 5.1, eftersom ExplorerOM är ett .NET Framework-assembly. I PowerShell 7 hoppas den delen över med en varning och WMI-delen körs ändå. Hanteringsdatabasen hämtas från registret om ni inte anger -ManagementServer och -ManagementDatabase.

Vad betyder noll och ”ej läst” i rapporten?

Noll betyder att läsningen lyckades och inte hittade några poster. ”Ej läst” betyder att antalet är okänt. Börja därför med att lösa eller dokumentera läsfelen. För inte över ”ej läst” som noll till kalkylatorn.

Summera inte raderna till ett antal integrationer. En orkestrering, en map och en port kan höra till samma verksamhetsflöde. Rapporten räknar artefakter; kopplingen till ett flöde behöver ni lägga till.

Varför saknas katalogens antal?

Rapportens varning skiljer mellan en överhoppad katalog, en ExplorerOM-komponent som inte kunde laddas och en katalog som inte gick att läsa. Kontrollera den orsaken först. WMI-rader med antal visar inte att katalogläsningen också lyckades. Om katalogen avsiktligt hoppades över med -SkipCatalog, anteckna det i underlaget.

Kan vi använda antalen som en migreringsbudget?

Antalen hjälper er att börja uppskatta arbetet. För en budget behövs också vilka artefakter som används, hur flödena hänger ihop och vad ett test visar. Prova ett avgränsat flöde innan ni använder samma antagande för resten av miljön.

Från rapport till ett underlag ni kan diskutera

1. Spara rapporten tillsammans med miljönamn, datum och vilka källor som gick att läsa.
2. Välj ett verksamhetsflöde och koppla det till de artefakter som faktiskt ingår.
3. Fyll i beroenderegistret med mottagare, delade resurser, ansvariga och öppna frågor.
4. Använd kända antal i kalkylatorn och stäm av uppskattningen mot ett pilotflöde.

Vad scriptet inte gör

De här tre egenskaperna är villkor för att skriptet ska gå att köra i en reglerad miljö, och de är med avsikt begränsande:

• Läsbehörighet räcker. Ingen BizTalk-databas skrivs till.
• Ingen extern uppladdning. Rapporten sparar en lokal rapport, till sökväg som anges.
• Ingen telemetri. Scriptet skickar ingen data, varken vid körning eller efteråt.

Begränsningar i denna beta

Filen är öppen för granskning. Läs koden innan körning och använd en uttrycklig lokal -OutputPath. Katalogläsningen kräver läsbehörighet till hanteringsdatabasen; utan den blir de fem raderna "ej läst". Betan läser inte bindings, assemblies, spårningsdata, meddelandevolym eller beroendegrafer och ger därför inget komplexitetsband. Använd kalkylatorn separat om ni vill pröva ett grovt intervall.