« Hem

BizTalk Server

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!

Ta ett steg tillbaks

Igår jobbade jag med en integration där jag hade följande scenario:

  1. En lagrad procedur i SQL Server levererar data till BizTalk
  2. BizTalk tar emot datan som XML via SQL adaptern och debatchar den, dvs. bryter ner datan i olika meddelanden
  3. Baserat på properties i meddelandet olika saker hända i en orkestrering

Jag började med att skapa ett schema för meddelandet i BizTalk, men fick genast problem med att få proceduren att leverera data enligt schemat. Jag testade alla möjliga varianter, men kom ingenstans. Det kändes ungefär som att dunka huvudet mot en betongvägg på olika ställen för att se om den skulle ge vika. Det gjorde den inte.

Till slut gav jag upp och lämnade datorn. Vilket såklart var det bästa jag kunde göra. Lite distans till skärmen och diskussion med kollegor gav mig en ny vinkling på problemet: jag ska såklart inte försöka tvinga in data från SQL i en struktur som jag skapat i BizTalk, utan låta SQL definiera schemat för den data som ska skickas. Jag tog då bort det gamla schemat och genererade ett nytt baserat på proceduren, vilket fungerade fint, och med hjälp av den här guiden lyckades jag få till hela flödet.

Jaha, och vad vill jag säga med detta?

Jo, jag vill påminna er (och kanske framförallt mig själv) om vad en bör göra när en kört fast i ett problem, nämligen att ta ett steg tillbaks. Lämna datorn, ta en promenad, gör något annat en stund. Du får då distans till problemet och kan se bortom det där hörnet som du har målat in dig i. Jag tycker det här gäller alla typer av problem, men det är extra tydligt när det gäller systemutveckling och integration. Ofta fastnar man i fel angreppssätt, som jag gjorde, och inser att problemet inte bör, eller ens kan, lösas på det sätt en tänkt från början, men att det inte alls är lika svårt från en annan infallsvinkel.

Bildresultat för step back

Best practices i Biztalk

BizTalk Server är en otroligt kraftfull integrationsplattform, men precis som med all mjukvara handlar mycket om hur man använder produkten. För att få ut det mesta av BizTalk, och för att skapa integrationer som är lätta att förstå och underhålla, finns det en del best practices som är bra att följa. Jag har sammanställt en lista av sådana som är viktiga för oss integrationsutvecklare i början på karriären. Enjoy!

Bildresultat för biztalk server

Sortera artefakter

Om du ska göra en mindre integration, med bara enstaka komponenter skapade i Visual Studio, kan du lägga alla filer i samma projekt. Så länge det handlar om ett fåtal filer är det enkelt att få överblick över integrationen, men när du börjar få flera olika pipelinekomponenter, orkestreringar och scheman och projektet växer, blir det lätt rörigt. Om du vet att det kommer tillkomma filer, lägg dem från början i olika projekt, baserat på vilken typ av artefakt det handlar om; ett projekt för scheman, ett för orkestreringar osv.

Namnstandard

Ofta finns det en namnstandard som antingen kunden eller ni själva har kommit överens om, så se till att följa den. Det här är förstås generellt för all utveckling och något jag tror de flesta har med sig detta från skolan, men det är faktiskt inte helt lätt i praktiken alla gånger. Jag sitter just nu med en integration där allt ska skrivas på svenska, vilket känns väldigt ovant, och jag har redan kommit på mig själv med att vilja bryta standarden flera gånger…

MSI

När du ska deploya integrationer och ändringar till BizTalk kan du göra på flera sätt, och det rekommenderade tillvägagångssättet är att använda en MSI, Microsoft Installer Package. Det gör installationen enkel och standardiserad och du minimerar risken missa något i installationen, eftersom MSIn innehåller alla dll-er du behöver.

Automatisera

Ytterligare ett steg i att minimera risker att något går fel i en deploy är att automatisera så många steg som möjligt. Ofta är det den mänskliga faktorn som ställer till det, och genom att skripta installationer standardiserar du tillvägagångssättet ytterligare och du behöver inte vara rädd att missa något steg i processen.

Visual Studio deploy

Om du har jobbat med BizTalk projekt i Visual Studio, har du säkert sett att det finns ett menyval som heter ”deploy”. Det här är jättesmidigt när du sitter på din egen utvecklingsmiljö och testar saker lokalt, men det alternativet ska aldrig användas i produktionsmiljö. Visual Studio stoppar nämligen portar och orkestreringar och du har ingen kontroll på hur det sker, och eventuella hjälp-klasser (dvs projekt i lösningen som inte är av typen BizTalk) följer inte med.

Kanoniska scheman

Väldigt många integrationer handlar om att konvertera ett meddelande till ett annat format för leverans mellan olika system, och vi använder då mappningar för att översätta dessa. En best practice är att alltid använda kanoniska scheman vid mappningar, dvs. att ha ett internt meddelandeformat som mellanhand, vilket gör att vi får en lösare koppling mellan systemen och att ändringar hos någon av parterna blir lättare att hantera.

Capture

Nu är det dags för mig att återgå till min integration! Det är fredag, och idag är vi många på kontoret: Magnus, Stefan, Micke och jag sitter här, tillsammans med Rikard som precis kommit tillbaks från sin föräldraledighet och sedan vår nya stjärna Stefan Rulli, som började här i mitten på augusti. Några av oss (eller okej, en av oss) kör på traditionen ”fancy friday” med slips och kavaj. Någon hade försökt lura Rulli att vi har ”pant-less friday”, men som tur är gick han inte på det…

Trevlig helg! :)

 

 

En integration från grunden

Vafalls, inget blogginlägg förra veckan? Skäms på mig!

Till mitt försvar kan jag dock säga att jag har haft fullt upp. Vi har dels varit i Finland och träffat våra finska kollegor i integrationsteamet på Fortum (mer om det senare!) och dessutom har vi startat ett nytt projekt, där jag är med och utvecklar integrationerna. Hittills i jobbet har jag mest hanterat befintliga integrationer, försökt förstå vad som händer och felsökt dem vid problem, men nu handlar det alltså om att bygga upp nya integrationer från grunden, vilket är väldigt spännande!

Jag tänkte ta det här tillfället i akt och beskriva hur detta kan göras. Vi har till en början två system som behöver kommunicera med varandra. Systemen, vi kan kalla dem A och B, exponerar webbtjänster (web services) mot omvärlden, och det är genom dessa som de kommunicerar med varandra. Webbtjänster är ett standardiserat sätt för applikationer att kommunicera över internet genom att skicka XML-meddelanden, utan att de behöver veta något om varandras interna logik.

Men, även om tjänsterna gör att applikationer kan kommunicera med varandra utan att känna till logiken, så krävs det ändå att de känner till vilken typ av XML-meddelanden som tjänsterna tar in och skickar tillbaks. Så länge vi bara har system A och B så är detta inget direkt problem, men vad händer när system C, D och E kommer in i bilden, och alla systemen behöver byta information med varandra?

Capture2

Helt plötsligt måste alla system vara medvetna om varandra, och ändringar i ett system påverkar alla som har kopplingar till det. Detta kallas ofta  ”point to point integration” eller ”spagettiintegration”, och de största nackdelen är att det efter ett tag blir svårt att hålla ordning på alla integrationer, och snart sitter man med en härva.. spagetti…

Spaghetti Girl

Bildkälla

Lösningen på det här problemet är, som jag har varit inne på tidigare, att använda en integrationsplattform, till exempel BizTalk Server, som sköter all kommunikation mellan systemen. Det blir betydligt lättare att övervaka alla transaktioner mellan systemen, och underlättar om ett system ska läggas till eller tas bort.

Capture

Men i alla fall – åter till den integrationen jag bygger! System A ska anropa en webbtjänst hos system B, men för att undvika framtida ”spagettiintegrationer” har vi skapat en mellanliggande webbtjänst i BizTalk som tar emot ett meddelande från system A och i sin tur anropar tjänsten hos system B. Det gör att systemen inte behöver veta något om varandras tekniker, och det är enkelt att lägga till ytterligare system som vill ha data från webbtjänsten.

Hur görs detta i praktiken då? Jo, vi har skapat något som kallas för en orkestrering i BizTalk och sedan exponerat den som en tjänst. En orkestrering är ett sätt att visuellt modellera ett processflöde för ett meddelande, och det kan se ut ungefär såhär:

ork2

System A anropar vår orkestrering, som alltså exponeras som en webbtjänst, och i orkestreringen kan vi sen grafiskt modellera vad vi vill ska hända. I det här fallet lagrar vi först en variabel, ett id som vi vill ha koll på under hela processen, sedan använder vi en ”sändmodul” för att göra ett anrop till B-s webbtjänst, och via en ”mottagningsmodul” tar vi emot svaret från den.

Svaret kommer i ett format specificerat för system B och i nästa steg använder vi en ”tilldelningsmodul” för plocka fram informationen som vi fick från B-s webbtjänst. Informationen berättar för oss om allt gick bra, och det kollar vi genom en beslutsmodul, vilket leder till ett vägskäl i processen: om allt gick bra vill vi lagra informationen vi fick tillbaks, och om det inte gjorde det sparar vi felmeddelandet från tjänsten.

Det allra sista vi gör är sedan att konstruera det meddelande som system A väntar sig tillbaks. Vi mappar då informationen som vi lagrade i vägvalet innan det till det format som A vill ha, och om allt har gått bra så skickas sedan svaret till system A. Det allra sista blocket är ett så kallat ”catch-block”, som är orkestreringens motsvarighet till ett catch-statement i kod, och det kommer fånga upp oväntade fel i orkestreringen. Om vi inte använder ett sådant block så kommer processen avstanna, och system A kommer stå och vänta på ett svar som aldrig kommer.

Förhoppningsvis ger detta lite inblick i hur en integration kan se ut i praktiken, även om det här blev en något förenklad beskrivning.

Nu önskar jag och Integrationsbolaget er en riktigt glad påsk!

 

 

Såhär kan en integration se ut

God eftermiddag! Återigen känns det som att veckan bara har flugit förbi och det är redan fredag. Den här veckan har jag haft fullt upp med att utöka en integration med ett nytt flöde, något jag tror jag nämnde i förra inlägget. Det första jag behövde göra var att förstå hur integrationen faktiskt fungerade, och jag tänkte använda det jag tagit reda på som ett exempel på hur ett integrationsflöde kan se ut.

Här kan ni se en översikt av flödet, och jag tänkte gå igenom steg för steg vad det är som händer.

integrationexempel1. XML och FTP

Vi har ett system som samlar in väderdata, till exempel temperaturen över en viss tidsperiod eller hur mycket nederbörd det kommit. Den här informationen lagras sedan i XML-format och sparas på en FTP-server, och det är genom att hämta XML-filerna på FTP-n som vi kommer åt informationen. Informationen från filerna kallas generellt för meddelanden när de går genom en integration.

2. BizTalk-port

BizTalk är den integrationsplattform som används i den här integrationen, och när filerna har lagts på FTP-n, så finns det portar i BizTalk som hämtar in dem. I dessa portar finns det sedan ”mappningar” som översätter de inkommande XML-filerna till ett internt XML-format. Detta är för att man ska kunna lägga till nya dataformat in i integrationen, utan att behöva ändra logiken internt. Allt man behöver göra är då att mappa över den nya filen till det interna formatet, sedan kan den behandlas på samma sätt som alla andra meddelanden. I porten finns även en mekanism som arkiverar all data som skickas in och lagrar den för senare användning, till exempel analys.

3. Inuti BizTalk

Här ska jag inte fördjupa mig i några detaljer, men kort sagt kan man säga att BizTalk använder något som heter orkestreringar för att styra processen. I det här flödet så valideras värdena i meddelanden, och beroende på resultatet av valideringen, så tar meddelandet olika vägar.

4. WCF-tjänst

Oavsett vilken väg meddelandet tagit, så kommer det i slutänden till en port i BizTalk, som skickar det vidare till en extern WCF-tjänst. Även på den här porten sker det mappningar, nu från det interna XML-formatet till en XML-fil som tjänsten kan hantera.

5. Ner i databasen

WCF-tjänsten anropar i sin tur en lagrad procedur i en SQL Server databas, som översätter meddelandet från XML till SQL och sparar ner informationen i databasen. Sedan kan det finnas andra system som prenumererar på de här värdena, då skickas en notifiering (via BizTalk) till dessa system och berättar att nu finns det nya värden att hämta.

Det här blev väldigt kortfattat, men jag tror vi nöjer oss så för den här gången! Min uppgift i det här är att utöka integrationen vid punkt 1, så vi kan ta in ytterligare ett filformat via vår FTP. Här ser man direkt fördelarna med att ha ett internt format att översätta till – jag behöver bara göra förändringen vid punkt 1, inuti BizTalk kan allt fortsätta funka som förut.

What if… allt går åt h*lvete?

Ja, vad händer om servern/servrarna som vår integrationsplattform BizTalk körs på brinner upp? Det vill vi ju helst inte tänka på. Jag menar, det är ju inte direkt troligt att det kommer hända! Vad är oddsen, de står ju säkert och bra där de står! Men… det var nog så de som skapade Titanic tänkte när de inte installerade tillräckligt med livbåtar för alla passagerare, och vi vet ju alla hur det gick, eller hur?

(Källa)

Jag tror människan är av naturen optimist. Inte alltid på individnivå, men som grupp tror jag att vi inte gärna vill tänka på det värsta som kan hända. Eller, rättelse: vi tänker nog en del på det och ryser vid tanken, men det är sällan vi funderar över det rationellt och gör en handlingsplan för hur vi ska agera om det skulle hända. Det finns till och med något som kallas ”optimism bias”, och som innebär att vi på ett mer eller mindre omedvetet plan tror att negativa händelser händer andra, men inte oss själva. Det kan göra att vi exempelvis inte skapar en backup plan för vår BizTalk miljö, om den skulle göra en Titanic…

Exploding-Computer-460x300

(Källa)

Varför sitter jag och funderar på det här då?

Jo, jag är nämligen delaktig i att skapa en guide till hur man gör en så kallad Disaster Recovery Plan (DRP) för BizTalk server. Det är i korta drag en plan för hur en kan återställa miljön om servern skulle krascha och produktionsmiljön går ner. Mina tidigare erfarenheter av backup är att lägga en fil i dropbox, och den recovery jag har gjort är att välja en fil att återställa i Word när ”programmet har utfört en förbjuden åtgärd och måste stängas ner”, så jag kan lova att det här är ett helt nytt område!

Jag har läst hela dagen idag och större delen av gårdagen och det finns väldigt mycket skrivet om detta, vilket inte direkt är en fördel eftersom det blir svårare att sålla ut vad som är viktigt och vad som är inaktuellt. Det finns också flera versioner av Biztalk att ta hänsyn till, samt ungefär 5342976 andra parametrar som spelar in, och ärligt talat har jag lite ont i huvudet just nu. Då är det tur att en har duktiga kollegor som leder arbetet!

Vi har, tack vare Alan Smith (som ledde BizTalk-kursen jag var på för några veckor sedan), två möjliga scenarion att utgå ifrån och som bestämmer vilken backup strategi som behövs. Om det räcker att sätta upp en ny, precis likadan miljö som fanns i produktionen, så behöver en ta vissa åtgärder för att kunna återskapa denna. Det kan dock vara så att BizTalk kör längre processer och att en då behöver återskapa det tillstånd som miljön befann sig i vid tidpunkten för kraschen, och då har en ett betydligt mer komplicerat jobb framför sig. Det jag håller på och läser in mig på just nu är vilka krav som krävs på backup-miljön och vilka konfigurationer som måste stämma överens för att en backup ska vara möjlig.

Att läsa kräver lugn och ro för min del, och därför har jag för första gången jobbat hemma idag. Det är en väldigt trevlig möjlighet i det här yrket och jag kan väl summera den här arbetsdagen som: produktiv, men lite tråkig. Skönt såklart att på morgonen kunna gå från sängen till datorn på typ tre minuter, men samtidigt blir man lite seg i knoppen av det. Känner mig ovanligt trött idag, och som sagt, lite smått uttråkad av att sitta ensam hemma hela dagen. Nu är iaf arbetsdagen slut och det börjar bli dags att ta av sig morgonrocken…

Halloween, halvdag och en handfast förklaring av systemintegration

Då var det fredag igen! Veckorna bara swischar förbi, tyckte nyss att det var måndag och jag presenterade min kollega Elias på bloggen. Som jag skrev då så tänkte jag lyfta fram mina grymma kollegor och låta dem berätta lite om vad de gör på Integrationsbolaget och vad som gör att de trivs på sitt jobb. Nästa vecka tror jag ni kommer få träffa Fredrik Mansfeld, vår alldeles egna SQL-guru.

Jag kan i alla fall berätta en av våra förmåner: vi jobbar bara halvdag dagen före aftnar och röda dagar. Eftersom det är Alla helgons dag imorgon innebär detta halvdag idag, och jag har dessutom tagit ut lite komptid så jag sitter just nu hemma med min kaffekopp och skriver detta. Veckan har gått bra och jag har faktiskt fått göra lite ”riktiga”, dvs. debiterbara, uppgifter: jag började veckan med att skriva klart den där lagrade proceduren i SQL Server, och därefter har jag börjat felsöka ett flöde i en av våra integrationer. Eller, felsöka är att ta i: jag har börjat sätta upp testmiljön lokalt och försökt förstå integrationsflödet. Det ser ut ungefär såhär: 

Systemintegration eller Londons tunnelbana

Eller nej, okej, det gör det inte. Det här är en karta över Londons tunnelbanesystem och vilka andraspråk som är vanligast vid de olika stationerna. (Kartan är inte min, hittade den här. Tack för det Oliver O’Brian, vem du än är.) Men det illustrerar poängen: det handlar alltså om en jäkla massa olika system som behöver skicka data till varandra och när en försöker illustrera detta ser det lätt rörigt ut. Problemet är att systemen inte kan förstå varandra rakt av, det är som att ett gäng människor från massor av olika länder som behöver kommunicera med varandra, men det blir bara kaos eftersom ingen kan något annat språk än sitt eget. Här kommer tolken in, som kan alla språk och som ställer sig i mitten och översätter vad människorna säger. På en teknisk nivå använder vi ofta BizTalk Server som tolk, Microsofts integrationsplattform som jag nämnt tidigare, men på en mer mänsklig nivå finns systemintegratören, vars uppgift är att se till att översättningsflödet fungerar smidigt och att ingen data förloras på vägen.

Nu i början känner jag mig ungefär som en tolk som vara kan vissa fraser av de olika språken, och så fort någon säger något behöver jag slå upp det i en ordbok för att kunna översätta åt mottagaren, vilket gör att flödet går trögt och jag blir svettig av att försöka hänga med. Det är dessutom inte en rak linje mellan sändare och mottagare – desto fler som är inblandade, desto mer komplexa blir flödena och det är inte bara att vidarebefordra ett meddelande från person A till person B, jag måste på vägen be om kompletterande information från person C, plocka isär meddelandet i mindre delar eftersom jag måste dubbelkolla med person Bs mamma och hon kan inte hantera stora meddelanden, gå till person As syster och be henne översätta en viss del av meddelandet, prata med person D för att kunna sätta ihop meddelandet igen i en form som person B förstår, och till slut återkoppla till person A om hur det gick.

I det fallet jag håller på att felsöka och förstå just nu trodde jag att det var person As syster blivit sjuk och inte översätter meddelandet som hon ska, men det visade sig att hon översätter alla andra meddelanden korrekt, förutom just en viss typ, så troligtvis är det person C som ger felaktig kompletterande information för vissa meddelanden och skickar meddelanden som inte stämmer överens med det kontrakt som systern kan översätta. Jag måste försöka få fram varför person C gör fel när det gäller vissa meddelanden genom att följa flödet och se hur meddelandet transformeras längs vägen, för att förstå vart just dessa meddelanden transformeras annorlunda än andra. Och det hade ju varit trevligt om en helt enkelt hade kunnat fråga person C vad felet var, men så simpelt är det såklart inte. Person C arbetar inte heller ensam utan tar hjälp av externa system för att skapa sin kompletterande information, och att veta vem hen pratar med och i vilken ordning är en komplex process i sig.

Men – nu tar vi helg och fortsätter med detta på måndag! Jag önskar er en trevlig helg och en mysig allhelgonahelg, vare sig ni kör på den amerikanska utklädnaden och godis, eller den mer stillsamma svenska varianten. Själv har jag svalt den amerikanska seden med hull och hår, så nu ska jag sy klart min clowndräkt jag tänkte ha på mig ikväll. Tanken är att köra på någonting i den här stilen:

Clown

Men känner jag mig själv och min förmåga rätt kommer det snarare bli såhär:

Clown

(Källa bild 1, Källa bild 2)

BizTalk Server 2013 – Developing Integration Solutions ELLER en utbildning i behovet av integration…

Det är med blandade känslor jag sitter här i hotellets lobby och reflekterar över veckan i Stockholm. Jag har varit på utbildning i AddSkills regi, nämligen BizTalk Server 2013 – Developing Integration Solutions. BizTalk Server är Microsofts integrationsplattform och alltså den programvara många använder för att implementera stora integrationsprojekt, och utbildningen var helt enkelt en crash course i de viktigaste delarna som ingår i BizTalk. Jag ska inte gå in djupare på kursens innehåll eller BizTalk nu, men för den som är nyfiken finns kursinnehållet här.

För att summera veckan: ja, det har varit en grymt lärorik vecka, men med både toppar och dalar. De flesta topparna och dalarna kan förklaras av detta:

20151015_145544

Ett aldrig sinande förråd av choklad har gjort att min blodsockerkurva liknat en seismograf under en jordbävning – hyperpigg ena stunden för att totaldäcka nästa. En lösning hade kunnat vara att helt enkelt inte äta av det. Jag valde den andra lösningen: äta hela tiden och vara i ett ständigt sockerrus. Det blir avgiftning när jag kommer hem…

Med tanke på att jag numera är Bloggare tvingade jag mina kära kurskamrater att vara med på bild, och jag har idag insett en sak om mig själv: jag är en värdelös fotograf. Ni ser ju nedan: fokus på helt fel ställen, kasst ljus och dålig vinkel. Den visar iaf datasalen där jag spenderat hela veckan tillsammans med ett härligt gäng människor från Sveriges alla hörn! Nåja, några av hörnen åtminstone, och ett par av dem är med via videolänk.

 20151015_144614

Det absolut bästa med kursen har dock varit snubben på bilden nedan.

20151015_144627

Han heter Alan Smith och har varit vår lärare hela veckan. En engelsman i Stockholm som kan allt värt att veta om BizTalk Server och systemintegration, och som dessutom delat med sig av sina erfarenheter av att använda BizTalk i olika projekt. Han har inte bara haft svar på alla frågor utan även kunnat förklara saker på ett tydligt och intressant sätt. När han i måndags började prata fick jag en otäck känsla av deja vu – hans röst lät läskigt bekant! Insikten slog mig ganska snart när han presenterade sig: jag har lyssnat på honom på Pluralsight. Han är dessutom MVP (Most Valuable Professional, mkt imponerande titel) för Microsoft sedan tio år tillbaks, och jag kan lugnt intyga att han är väldigt kvalificerad att leda en sån här utbildning.

Utbildningen har som sagt handlat om integration och idag, näst sista dagen, fick jag dessutom själv uppleva ett klockrent exempel på behovet av att integrera system med varandra.

Mitt mål med den här utbildningen har varit att ta en certifiering i BizTalk Server, en examination som ges av Microsoft och som sköts rent praktiskt av Addskills. I tisdags blev jag sugen på att göra ett försök redan den här veckan och så jag anmälde mig via Addskills hemsida för att göra testet. Jag fick en bekräftelse på att jag var anmäld och har ägnat varje vaken minut åt att plugga hela veckan. Jag såg tidigare på Microsofts hemsida att det var en notis om att just den här certifieringen var ”expired”, men tänkte inte mer på det – om det hade varit några konstigheter så borde ju någon ha reagerat på min anmälan till ett prov som inte finns. För säkerhets skull skickade jag ett mail till Addskills idag och frågade dem – och fick då till svar att nej tyvärr, den certifieringen finns inte längre. Jag läste mailet i chocktillstånd och gick till receptionen för att höra vad det var som hände. Och jodå, de beklagade sig, men tyvärr hade Microsoft tagit bort just den examen.

Tydligen fanns det ingen koppling mellan Microsoft och Addskills system för att administrera dessa tester, och personalen från Addskills måste manuellt gå in på Microsofts hemsida och se vilka tester som finns och sedan manuellt uppdatera sitt utbud. Nu hade ingen gjort det på ett tag och följaktligen hade ingen sett att just den här certifieringen försvunnit från Microsofts utbud. Det krävs inget affärssnille för att förstå att ett företag förlorar på sådana här misstag, och det krävs ingen integrationsexpert för att se möjligheterna att inte bara automatisera utan även förbättra de processer som finns här.

Nu vet jag såklart inte om Addskills redan har försökt med detta och att det inte är tekniskt möjligt, men jag tycker det är sjukt intressant när sådana här scenarion dyker upp och jag ser exempel i verkligheten där systemintegration skulle kunna tillföra stort värde för ett företag. Jo, jag blev såklart väldigt besviken också, då jag var helt inställd på att göra testet imorgon, menmen, det kommer nya tillfällen. Och nu fick jag ju möjlighet att sitta i hotellbaren med ett glas vin och skriva detta istället för att plugga… ;)

Language: