« Hem

BizTalk Server – fem vanliga misstag

Jag har tidigare skrivit en del om BizTalk Server, som är Microsofts integrationsplattform och den vi på Integrationsbolaget använder mest, åtminstone i Örebro och Stockholm. När jag började jobba hade jag bara en vag aning om vad BizTalk var, ännu mindre om hur en faktiskt använder plattformen, och det var en hyfsat brant inlärningskurva under de första veckorna. Idag, nästan tio månader(!!!) senare, börjar jag känna mig bekväm med BizTalk. Jag kan snabbt sätta upp ett enkelt dataflöde och det har blivit betydligt lättare att förstå befintliga lösningar – så länge de är byggda på ett hyfsat vettigt sätt. Och detta leder mig in på ämnet för dagens blogginlägg:

Vanliga misstag inom BizTalk Server

1. Placera alla komponenter i samma VS-projekt

Det finns fem komponenter som du troligtvis kommer hantera i Visual Studio:

  • Orkestreringar
  • Pipelines
  • Mappningar
  • Scheman
  • Ev. hjälpklasser

I början har du kanske bara ett par instanser av varje komponent, och det är smidigt att lägga dessa i samma projekt. Men snart växer lösningen och plötsligt sitter du med ett projekt som innehåller massor av olika delar och när du behöver uppdatera en av dem får du genast problem, eftersom allt måste kompileras om även om du bara ändrar på en liten detalj i ett schema.

Tips: Ett projekt för varje typ komponent. Det kommer underlätta vid ändringar, plus att personen som bygger vidare på projektet lätt kan få en överblick över lösningen.

2. Placera alla integrationer i samma BizTalk applikation

I BizTalk Servers administrationsgränssnitt kan du dela upp integrationerna i olika applikationer. Det är ett misstag att inte göra detta! Visst är det enkelt att göra det till en början, men snart kommer applikationen att svämma över av logik som inte har något med varandra att göra, det blir svårt att separera flöden från varandra och plötsligt sitter du där med en spagetti-applikation som bara du förstår.

Tips: det kan vara svårt att göra avgränsningar, men ett generellt tips är en applikation per logisk enhet eller integrationsflöde. Är du ny? Fråga dina kollegor!

3. Dålig namnsättning

Det här är ett generellt problem för newbies inom programmering/systemutveckling, men jag tycker det är extra viktigt inom just systemintegration. Precis som i all programmering är det viktigt med rätt namn på metoder och klasser, men det blir ännu tydligare gällande portar, orkestreringar och mappningar. I en metod kan du oftast läsa dig till vad den gör, eller i värsta fall köra koden och debugga den för att förstå den. De olika delarna i en integration kan dock inte testas lika enkelt, och ordentlig namnsättning gör att flödet av data blir tydligare för den som ska underhålla applikationen efter dig.

Tips: namnkonventioner varierar mellan olika företag, så se till att kolla vad som gäller för just ditt projekt. Det finns en del generella guidelines, som du kan läsa om exempelvis här eller här.

4. Uppfinna hjulet på nytt

Såhär är det: det allra mesta har gjorts förut. Speciellt de förhållandevis ”enkla” uppgifter som nybörjare ofta får på en arbetsplats, så det finns ingen anledning att försöka göra egna varianter – speciellt när det gäller BizTalk och de adaptrar som finns out of the box. Integrationen blir lättare att förstå, underhålla och konfigurera genom de verktyg som finns, snarare än att skriva egen kod. Ny, egenskriven kod är dessutom betydligt mindre robust gentemot de färdiga lösningar som redan finns och används.

Tips: Läs på om de adaptrar som BizTalk har out of the box, och börja alltid med att leta färdiga lösningar på ditt problem, innan du försöker lösa det på egen hand. Se också till att du har koll på standardiserade sätt att göra saker, exempelvis hur du exponerar en orkestrering som en webbtjänst, eller konsumerar en webbtjänst från en sendport. BizTalk har metoder för att göra detta – följ dem istället för att försöka lösa det på egen hand.

5. Bygga alltför komplexa flöden

Det här är en riktigt svår fråga att besvara som nybörjare: vilken logik hör faktiskt hemma i BizTalk och vad hör hemma hos de olika systemen? När en kommit över den första inlärningskurvan så inser en ganska snabbt: du kan göra i stort sett vad som helst med BizTalk. Vilket problem du än har så går det med största sannolikhet att göra med BizTalk och ett par egenskrivna hjälpklasser. Men, bara för att det går att göra betyder det inte att du ska göra det.

Tips: Generellt sett brukar en säga att processlogik och konverteringar hör hemma i BizTalk, men att affärslogik ska hållas i respektive system. Det här är inte alltid möjligt, så är du osäker på om en viss logik bör ligga i en orkestrering eller någon annanstans – fråga en senior kollega!

Det var allt för den här gången! Midsommarveckan har precis börjat och semestern närmar sig med stormsteg för många av oss. En annan har några veckors jobb kvar innan det blir dags för ledighet, så räkna med ett par inlägg till innan bloggen tar sommarlov! 

BizTalk Server – de 4 största nybörjarmisstagen

Inför inledningen till det här blogginlägget satt jag och googlade på ”mistake quotes”, och jag hittade en hel del om relationer och livet i allmänhet, typ ”Det är mänskligt att göra misstag” och ”gör du inga misstag så har du inte försökt” . Ord som parafraserats alldeles för många gånger, ”memefierats” och helt dränerats på betydelse. Ändå ligger det något korn av sanning i dessa klyschor. Som någon sa: ”Your best teacher is your last mistake”, och visst är det så. Jag gjorde mitt senaste misstag för ungefär två timmar sedan nu, och oj vad jag lärde mig av det…

Det finns ju dock en viss mening i att inte göra alla misstag själv, utan lära sig av andras. Därför tänkte jag dela med mig av de, enligt mig, 4 största nybörjarmisstagen som nästan alla gör i början av BizTalk karriären. Eller ja, alla utom du, eftersom du nu lär dig av mina misstag och kan undvika dem. Förhoppningsvis.

Kolla vad som egentligen händer

Det största felet som nybörjare inom programmering gör generellt är nog att inte läsa felmeddelanden utan sitter och bara kliar sig i huvudet av förvirring när saker inte funkar. Samma gäller inom BizTalk – du måste ta reda på vad som händer när det verkar som att ingenting händer. Min process för att göra detta ser ut som följer:

1. Första steget är alltid att se om det finns några suspenderade meddelanden i BizTalk Group Hub. Meddelanden försvinner inte i tomma intet (även om det ibland känns så!) och vid de flesta felen så fastnar (suspenderas) det meddelande du försökte skicka och du kan kolla på innehållet samt det felmeddelande som.

capture2

2. Hittar du inget där, är nästa steg att ta en titt i eventloggen, där information, varningar och fel från bland annat BizTalk loggas.

capture

3. Om jag inte hittat något fel i eventloggen brukar jag använda tracking för att se om meddelandet tagit den vägen genom integrationen som jag har tänkt. Tracking visar helt enkelt hur meddelandet såg ut när det kom in till porten eller orkestrering och hur det ser ut när det bearbetats och skickats vidare till nästa instans. Ofta kan man på det här sättet spåra vad det är som händer i integrationen.

capture3

Den här processen sviker sällan – och om den gör det så beror det troligtvis på något av kommande vanliga misstag. En bonus för att felsöka orkestreringar är att använda debugviewer, ett verktyg som låter oss läsa meddelanden vi skriver i koden med hjälp av ex. System.Diagnostics.Trace.WriteLine(). Glöm inte heller bort att det går att attacha en debugprocess i Visual Studio till BizTalk, så du kan steppa igenom koden rad för rad, samtidigt som den körs.

Skit in, skit ut

När jag har bankat huvudet mot en vägg gällande ett problem i flera timmar och inte förstår vart i processen felet ligger, är det här ofta orsaken. Anledningen till att jag inte förstår felet är enkel – det finns inget fel. Det är meddelandet som jag försöker skicka igenom integrationen som inte är korrekt.

Bildresultat för shit in shit out

Glöm inte gaccen!

Jag har varit inne på ämnet GAC och att ”gacca” assemblys tidigare, troligtvis var det i samband med *saker som jag önskar att jag lärt mig i skolan*. ”Gaccen” är (mycket förenklat för min egen skull, klockan närmar sig 17 och det är fredag) en folder där alla assemblys måste ligga, för att BizTalk ska kunna komma åt dem. Alla scheman, orkestreringar, pipelines, hjälpklasser – allt måste ligga här för att integrationen ska rulla. Har du gjort en förändring i koden som inte verkar funka? Kolla så den nya versionen av assemblyn är gaccad ordentligt.

Har du startat om host instansen?

Det här är det överlägset största misstaget man gör som nybörjare, och jag kan nog inte ens räkna hur många gånger det hänt mig. En host är en logisk container för BizTalk objekt, och en host instans är dess fysiska representant, återigen väldigt förenklat.

capture4

Bildkälla

Vid varje ny deploy så måste berörda host instanser startas om för att förändringarna ska registreras av BizTalk. Host instanserna kan också vara förklaringen till att en receive location inte plockar upp meddelanden som den ska – är hosten stoppad, så kan inte BizTalk ta in meddeladet. Jag har blivit bättre på att komma ihåg det här numera, men det har tagit tid att få in rutinen att alltid kolla status och starta om dem vid behov.

Med detta önskar jag er alla en trevlig helg!

Language: