Kartlägg beroenden innan ni migrerar BizTalk
Ett beroenderegister visar vad ett flöde behöver för att fungera och vad som påverkas om det ändras. Börja med ett verksamhetsflöde och anteckna system, delade artefakter, mottagare och ansvariga. Lägg en källa och en verifieringsstatus på varje relation, så blir det tydligt vad ni vet och vad ni behöver undersöka.
Ta med registret till genomgången
Hämta tomt beroenderegister (CSV)
Hämta ifyllt exempel (CSV). Öppna filerna som UTF-8 med semikolon som avgränsare. Mallen är vårt arbetsunderlag och fylls i manuellt; den är inget exportformat från BizTalk.
Vad behöver vi dokumentera?
Skriv en rad per relation, inte en rad per applikation. Samma flöde kan till exempel behöva både en gemensam map och en mottagare som ska kvittera leveransen. Med separata rader kan ni följa upp dem var för sig.
- Flöde och beroende
- Vad verksamheten vill få gjort, vilken komponent eller motpart som behövs och i vilken riktning relationen går.
- Delning och ansvar
- Vilka andra flöden som använder samma resurs, vem som kan förklara den och vem som godkänner resultatet.
- Källa och status
- Var uppgiften kommer ifrån. Använd exempelvis ”att kontrollera”, ”dokumenterat” och ”testat”. Dokumentation och ett lyckat prov är olika slags underlag.
- Felväg och återställning
- Hur ni märker att leveransen saknas, vad som händer med meddelandet och vem som beslutar om återkörning.
Tomma fält är frågor att ta med till rätt person. Skriv hellre ”okänd” än att gissa. Förvara miljöuppgifter och interna dokument hos er; registret behöver inga lösenord eller anslutningssträngar.
Var hittar vi BizTalk-flödenas beroenden?
Microsoft beskriver beroenden mellan artefakter och applikationer: en orkestrering kan till exempel behöva ett schema eller en pipeline. Referenser mellan applikationer påverkar hur de kan distribueras och underhållas. Följ därför även delade artefakter över applikationsgränser. Microsofts beskrivning av beroenden, läst 2026-10-03.
Bindings kopplar logiska ändpunkter till fysiska ändpunkter. En bindingfil innehåller bland annat värdar och inställningar för portar, receive locations och parties inom exportens omfång. Den hjälper er att hitta tekniska kopplingar, medan ansvar och verksamhetskrav behöver kompletteras. Microsofts beskrivning av bindingfiler, läst 2026-10-03.
- Börja med en artefaktinventering och kontrollera vilka delar som gick att läsa. Skriptets beta tar inte fram en beroendegraf.
- Gå igenom applikationsreferenser och relevant bindingunderlag med den som förvaltar flödet. Anteckna källa och miljö för varje uppgift.
- Följ ett representativt, maskerat meddelande från avsändare till mottagare. Koppla testunderlaget till relationerna i registret.
- Stäm av tidsfönster, kvittenser och återkörning med motparten. Spara obesvarade frågor på egna rader.
Exempel: en order ska nå ett lager
Det här är ett illustrativt flöde med påhittade namn. Ordern kommer från ett affärssystem, går genom en gemensam map och skickas till ett lager. Vi vet hur det är beskrivet, men behöver fortfarande prova vad som händer när lagret inte svarar.
| Beroende | Vad vi har | Vad vi behöver göra |
|---|---|---|
| Affärssystem → OrderTillLager | Ett beskrivet orderformat; status dokumenterat. | Kontrollera att testmeddelandet täcker de fält lagret behöver. |
| OrderTillLager → GemensamOrderMap | En beskriven delad map; status att kontrollera. | Ta reda på vilka andra flöden som använder den och ta med dem i testet. |
| OrderTillLager → Lager | Ett beskrivet mottagarkontrakt; status dokumenterat. | Prova uteblivet svar och bestäm hur samma order kan återköras utan oönskad dubblett. |
Nu finns konkreta frågor att planera efter. Flödet är inte färdigt att flytta bara för att alla tre rader är ifyllda. Låt testresultaten och motpartens godkännande avgöra vad som kan markeras som verifierat.
Hur väljer vi ett pilotflöde med hjälp av registret?
Välj ett flöde där ni kan följa hela leveransen, få hjälp av mottagaren och prova en relevant felväg. Det ger ett användbart första underlag för arbetet med resten av miljön.
- Finns det en ansvarig som kan godkänna både innehåll och leverans?
- Kan ni avgränsa delade resurser utan att missa andra berörda flöden?
- Finns testmeddelanden och en tydlig förväntan på resultatet?
- Vet ni hur provet återställs om något går fel?
Ta därefter registret vidare till testplanen för migrerade flöden. När ni har ett provat arbetssätt kan ni diskutera migreringsvägarna med bättre underlag. Lägg nya fynd och ändrade beroenden i samma register, så följer frågorna med genom projektet.