« Hem

Systemintegration

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! :)

 

 

Det svåra med kravhantering

Jag har ju tidigare skrivit om att det är jäkligt svårt att tidsuppskatta arbetsuppgifter när det gäller IT, och ytterligare ett problem som relaterar till detta är att hantera de krav som finns på den lösning som ska byggas. Till skillnad från  tidsuppskattningen är det här något som faktiskt tas upp i informatikutbildningen, så har du läst systemvetenskapliga programmet är du antagligen medveten om problematiken.

dilbertProblematiken simuleras i åtminstone en kurs där lärare agerar ”kunder” som plötsligt ändrar sig under ett projekt, och jag minns att många studenter blev irriterade på detta. I skolan är man inte van att nya saker dyker upp mitt under ett projekt, allt brukar (och ska enligt regler kring betygssättning) vara specificerat från början, så studenten vet exakt vad som förväntas. I yrkeslivet är läget dock ett annat, vilket lärarna i informatik gör sitt bästa för att förbereda studenterna på.

Jag tycker att de gör ett bra jobb med detta, men det är ändå otroligt stor skillnad att vara med om det i verkligheten. Problemet med att nya krav dyker upp från kunden är dock inte så stort för mig, eftersom jag mest jobbar med mindre, ganska avgränsade uppgifter som redan definierats. Det största bekymret för mig är snarare att förstå de krav som redan finns. För det mesta går processen till såhär:

  1. Jag får en uppgift, ofta specificerad via mail
  2. Jag tänker: jag fattar. Det här fixar jag direkt.
  3. Jag startar Visual Studio, BizTalk eller vad det nu kan vara för programvara som krävs
  4. Och tänker: men vänta här nu. Vad exakt är det som ska hända här egentligen?

Det som verkar så lättfattligt i mailet blir plötsligt betydligt mer oklart när jag ska börja skriva koden, och jag måste ofta gå tillbaks och ställa mer frågor för att kunna lösa uppgiften. Ju mer detaljer jag grottar ner mig i, desto fler blir frågetecknen och ofta visar sig uppgiften vara betydligt större och mer komplicerad än jag trott från början.

Varför är detta så svårt egentligen?

Jag har en teori och det är att IT är så otroligt abstrakt, både för den som ska använda lösningen, men också för den som ska programmera, innan denne har verkligen börjat koda. Ska man bygga en bro är det betydligt enklare: vi ska från punkt A till punkt B och eventuella problem längs vägen är betydligt lättare att förutse. Alla kan direkt se att en promenadbro över en liten bäck kommer vara betydligt enklare än en bro för biltrafik över en stor älv.

1tower-bridge

I IT är det inte lika enkelt: det som från början kan se ut som en promenadbro visar sig vara en klaffbro över ett vattendrag med båttrafik när kraven börjar analyseras. Det som från utsidan, och kanske främst från en användares sida, ser enkelt ut, är bara toppen på ett isberg av kod och komplexa beroenden, som ofta är svåra att förutse. Och framför allt: ingen skulle föreslå att man skulle bygga över Mälaren på ett par veckor, men inom IT händer det ständigt.

Jag har själv försökt mig på det – jag trodde att jag skulle kunna bygga en hemsida med ett eget CMS på några veckor, utan att inse de många timmar som ligger bakom ett administratörsgränssnitt som ex. WordPress. För att göra en lång historia kort: det gick inte alls. Det blev bara en hemsida och administratören fick administrera i HTML istället… Här har vi ett praktexempel på när en inte tillräckligt tydlig kravbild totalt pajar den tidsuppskattning som gjorts, och jag hade egentligen två val: öka tiden eller minska på kraven, och jag valde det senare.

Men, precis som med tidsuppskattning så går det att bli bättre på det här också! Ju mer man jobbar med en viss typ av lösningar, desto mer förförståelse får man för de olika delar som kan bli besvärliga, och man lär sig också att ställa mer och bättre frågor kring vad som ska göras. Man ser helt enkelt tydligare om det är en liten träbro eller en järnvägsbro som ska byggas, och kan anpassa jobbet därefter.

Nu har klockan slagit fem denna fredag, och jag lämnar er med den här klassiska bilden kring kravhantering. Det är möjligt att den är en sliten klyscha i sammanhanget, men den illustrerar ändå problematiken väldigt bra.

business-requirements-management

Trevlig helg på er!

Integratören == Spindelmannen

God förmiddag!

Kommer ni ihåg att jag skrev att jag hade ett möte med folk från Finland, Indien, Tyskland och Ryssland för ett tag sedan? Då diskuterade vi en integration mellan företagets HR-system, där användaren knappar in data om anställda, och Active Directory, där datan lagras. Jag har utvecklat den här integrationen och implementerat den i testmiljön, så nu sitter jag i ett möte där flödet ska testas från början till slut. Eller möte är egentligen fel ord – vi har en testsession på ca 4h, där någon från varje ansvarsområde är tillgänglig.

Det är väldigt spännande, även om det såklart dyker upp nya problem som vi inte förutspådde innan. Det är ju anledningen till testerna, och jag tror att det är väldigt få IT-lösningar som fungerar perfekt på en gång. Hursomhelst, jag fick en ganska skum känsla när vi började testerna: jag kände mig helt plötsligt jäkligt viktig. Inte så att jag går runt och känner mig försumbar i vanliga fall, men i det här scenariot tyckte jag det blev extra tydligt att integrationen är hjärtat i det dataflöde vi vill skapa, och jag som integratör är en Very Important Person.

Visst, det här är min subjektiva åsikt, och de flesta tycker säkert ens egna område är det viktigaste. Typ som lärare i skolan: nå, det är väl bra att det finns andra ämnen, men det är just mitt ämne som du faktiskt behöver kunna. Men jag tycker ändå jag har en poäng här: utan integrationen kan inte systemen kommunicera med varandra, och då finns det liksom inget flöde, oavsett hur bra övriga system funkar. Integratören är också den som måste ha koll på hur de olika systemen kommunicerar: vilken typ av data skickar HR-systemet ut? Vad är det egentligen AD vill ha för att kunna lagra information om anställda? Vilka konverteringar behöver vi göra? Hur ska responset se ut? För att använda ett slitet uttryck: integratören är spindeln i nätet här. Som den här snubben.

spider-man

Typ.

Uttrycket är klyschigt, men det stämmer. Precis som vi skriver på vår infosida om att driva integrationsprojekt: ”Det är ofta en stor utmaning då [integrations-]projekten av naturen kräver kommunikation mellan fler parter (som ofta inte befinner sig på samma plats). Integratörens roll får alltid inslag av projektledning och kravställning eftersom man nästan alltid får en väldigt central roll i projektorganisationen.”

Nu ska jag inte gå så långt som att säga att jag varit inblandad i projektledningen i det här fallet, eftersom jag bara haft ansvar för just den här integrationen, men jag ser ändå utmaningarna. Som till exempel i den här testsessionen, då vi är folk från totalt sex länder i olika tidszoner. Visst är det lite svettigt med första testet av något jag har byggt, men jag tycker coolhetsfaktorn väger över. Här sitter jag och är internationell liksom!

Myter om jobbet som IT-konsult

Finns det myter om IT-konsulter? Jag hade ett par förutfattade meningar kring yrket innan jag började, och för att få ytterligare kött på benen ställde jag frågan i facebookforumet ”Kodapor OT” – stort tack till er som svarade! Detta är ett ihopkok av mina tankar och svaren jag fick där, och mina åsikter kring huruvida stereotyperna stämmer.

1. Vi är antisociala killar som gillar Joltcola

Ungefär som Dennis Nedry i Jurassic Park, han som kodat hela parkens IT-system alldeles själv och ser ut såhär:

thumbnailImage

Jag tror att alla rent logiskt fattar att det här inte längre stämmer: du behöver inte vara en lonely gamer som sitter i en källare och spelar WOW hela nätterna för att vara bra på programmering/IT. MEN. Det är fortfarande underskott på kvinnor i branschen och även om utvecklingen går framåt så tar det tid att bryta mansdominansen i yrket. Jag försöker dra mitt strå till stacken genom den här bloggen, där jag vill visa att du inte behöver tillhöra Dennis Nedry-normen för att jobba som IT-konsult.

2. Vi är gifta med våra jobb

Vi som jobbar med programmering/systemutveckling har det som ett kall och något vi gärna gör gratis på fritiden. Du förväntas kunna visa upp egna, spännande projekt som du skapat utanför studier/jobbet, för att bevisa att du inte bara är bra på ditt jobb – du är ett med jobbet, det är ditt jag och din identitet.

Den här är svår, och en av de största förutfattade meningarna jag hade innan jag började jobba, vilket jag nämnt tidigare.

Åh ena sidan: ett jobb är bara ett jobb, och det är faktiskt helt okej att ägna fritiden åt andra saker än programmering. En av de saker som jag hoppas jag har fått fram i den här bloggen är att du inte behöver vara underbarn som monterade datorer vid 3 års ålder för att vara en bra IT-konsult.

Åh andra sidan så kräver jobbet otroligt engagemang i hjärnan, det går inte att programmera och tänka på annat samtidigt. (Åtminstone kan inte jag det…) Det kräver dedikation och en vilja att lösa problem, ett sug efter att leverera lösningar, och den här dedikationen har en tendens att sprida sig utöver de där timmarna mellan åtta och fem. Risken är stor att om du är gift med något annat än jobbet, så kommer jobbet vara ett rätt så krävande vänsterprassel.

Här har jag dock en teori: det är lätt att gifta sig med jobbet, när allt som krävs är en dator och internetuppkoppling. Människor kan garanterat känna samma dedikation i alla yrken, men det är inte lika lätt att leva ut när jobbet kräver aktioner på plats. Till exempel: en undersköterska som stannar kvar efter sitt pass ses som konstig, men den IT-konsult som gör samma sak, det är bara vardag.

3. Vi kan allt.

När jag ställde frågan på facebookforumet om vilka fördomar folk upplevt som kodapor var första kommentaren detta:

Vad jobbar du med då?
 - Jag är programmerare.
 a) Jaha, kan du göra en hemsida åt mig?
 b) Du, min dator är långsam, kan du titta på den?

Med andra ord: många tror att vi kan när det gäller datorer, vare sig det gäller att göra grafik till en hemsida eller en trasig dator.

IT är ett väldigt, väldigt, väldigt stort ämne och för att bli riktigt bra behöver du välja ett område att bli bra inom, annars finns det helt enkelt inte tillräckligt med livstid för att lära sig allt. Dock så blir jag ständigt imponerad över de olika gurus som finns därute och som har samlat på sig så otroligt mycket kunskap kring olika aspekter av vårt jobb – en eloge till er!

4. Vi kan ingenting

Ytterligare en myt är motsatsen till ovanstående, nämligen illusionen av att det vi gör är jättelätt och inget som kräver någon direkt ansträngning. Citat från facebooktråden i Kodapor OT: ”Fan vad skönt att vara programmerare, då kan man bara sitta i en stol vid datorn hela dagen och dricka kaffe istället för att slita och vara stressad på ett riktigt jobb.”

Min fördom kring folk som har den här fördomen är att de har en liten inblick i kodning och hur det fungerar. De kanske har skrivit ett par rader i något programspråk, men har ingen djupare insikt om vilka problem som dyker upp, vilket leder till att de tror att allt är enkelt löst med en if-sats. Ytterligare en situation när den här mentaliteten dyker upp är vid prototypvisningar: för den som tittar ser det ut som att produkten är färdig, men egentligen är den bara ett tomt skal, och de inser inte att det är betydligt svårare att implementera animationer och snygga flöden i kod än att rita upp det i Photoshop.

Sanningen ligger någonstans mittemellan: ja, det är komplext och ingen barnlek att implementera en idé i kod, men det är samtidigt inte magi, och låt inte den här komplexiteten skrämma bort dig. Jag tror att alla som är motiverade till det kan lära sig koda, och när den första tröskeln är överstigen så kommer det kännas lättare. Det svåra är inte att skriva koden utan att veta vad som ska skrivas.

5. Vi hoppar på vilket projekt som helst

Det här är lite sammankopplat med illusionen om att programmering är ett kall som vi gärna gör gratis på fritiden, och jag tycker nedanstående bild illustrerar det här väldigt bra:

13083260_10153542473356981_2475047108041777606_n

Detta har nog hänt många programmerare, och som en i Kodapor OT formulerade det: ”- Du jag har en unik app/spel/webbsideidé som du kan hjälpa mig med! (jag berättar vad jag vill ha och du gör det faktiska jobbet.)” Gärna utan betalt, med motiveringen att ”det är ju något att sätta på CV-t” och att det är idén som är värd något, inte implementationen. Det hänger också ihop med illusionen om att programmering är enkelt. Och visst, att skriva en funktion som tar en en sak och returnerar en annan är enkelt, men det är vägen från ”jag vill ha en app som gör x och y” till enskilda klasser, attribut och funktioner som är det svåra, vilket jag tror många underskattar.

Bubblare

Det verkar också finnas en del myter från andra yrkesroller i branschen, så vi tar ett gäng bubblare också:

  • Att en kodare bara kan koda och inget annat
  • Att kodare bara ska koda och ingenting annat
  • Att konsulter tar överpris och har sjukligt höga löner, helt i onödan
  • Vi har ju nästan byggt ett sånt system, vi kan väl utgå från det och bara ändra lite, det är väl redan modultänk så det är lätt att lägga till och ändra moduler? Så sparar vi tid.
  • Att det är möjligt att följa exakt samma kodstandarder som i tidigare projekt, även om det är i olika språk
  • Att man vill hjälpa alla med deras datamaskin
  • Missuppfattningen att vi bygger bilen när vi i själva verket bygger ritningen till bilen. Datorn bygger bilen (maskinkoden) utifrån ritningen (källkoden).
  • Att man förväntas vara expert på allt som alla avdelningar jobbar och pratar om bara för att det råkar visas på deras skärm
  • Att teknisk skuld är detsamma som buggar.

För att summera: det finns en jäkla massa fördomar och myter kring det här jobbet! Och då har jag ändå begränsat mig i urvalet från svaren i facebookgruppen. Vad tycker du? Har du myter att krossa eller bekräfta? Lämna en kommentar!

 

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!

 

 

Vaddå deploy?

I skolans värld jobbar man mycket med de små detaljerna. Det handlar om att få enskilda metoder att fungera, och att sätta ihop dem till ett program som förhoppningsvis både kompilerar och sedan fungerar som tänkt vid körning. Jag minns när vi gjorde vårt allra första projekt i Java och hur stora problem det blev med de hårdkodade sökvägarna till databasen och hjälpfilerna i programmet. Vid inlämning skulle programmet zippas ihop och skickas till lärare och opponenter, och i åtta fall av tio fungerade det inte att köra på någon annan dator, vilket var frustrerande för alla parter.

I det skedet av utbildningen var det ingen lärare som pratade om det (antagligen för att inte överhetta våra redan kokande hjärnor) men det här var egentligen den första, lilla erfarenheten som vi hade av det som kallas deploy. Jag har försökt leta efter ett bra svenskt ord för det, men jag hittar inget klockrent. Enligt google translate är sprida, gruppera eller ”utveckla på bred front” lämpliga översättningar men om man ser till engelska definitioner av begreppet så säger Merriam-Webster att deploy är ”to organize and send out (people or things) to be used for a particular purpose”. Produktionssättning eller driftsättning är svenska ord som kommer rätt nära, men de täcker inte riktigt in hela begreppet. Det behöver inte handla om att lägga in något i produktionsmiljö, eller göra stora förändringar, utan deploy kan även handla om små saker eller förändringar som ska implementeras i en ny miljö. Uttrycket har även blivit försvenskat och vi pratar om att ”deploya” kod eller att den här ”deployen” inte gick som den skulle

Varför sitter jag och funderar på det här med deploy då? Jo, jag ska nämligen deploya en del kodändringar i en integration som jag utvecklat lokalt till vår testmiljö – och det är inte helt enkelt! Att deploya till test är visserligen inte lika kritiskt som att göra det i produktion, men man vill ändå inte störa dataflödet och definitivt inte deploya något som visar sig inte funka.

Vad är viktigt att tänka på när det gäller en deploy?

Tja, det beror såklart helt på hur processen ser ut. I mitt fall handlar det om att uppdatera dll-er som ligger på testservern med de nya versionerna som jag har byggt ihop lokalt, men oavsett hur det ska göras är nyckelordet alltid: backup. Vi har en metod som vi använder för detta:

  1. Se till att det finns en dedikerad backup-mapp på servern
  2. Skapa en ny folder i den med dagens datum
  3. Inuti den nya foldern skapar du ytterligare två mappar, en som heter IN och en som heter OUT.
  4. I IN-mappen lägger du in de nya ändringarna som du gjort, och i OUT-mappen lägger du en kopia på den befintliga, fungerande miljön.

Sen är det bara att lägga in ändringarna i testmiljön, och om något går snett så kan man göra en rollback genom den backup man har i OUT-mappen.

 

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.

En helt vanlig dag.

Mina dagar börjar alltid med att jag sätter på kaffe så fort jag kommer till kontoret, om ingen annan har gjort det. Som så många andra i det här landet har jag utvecklat ett beroende till den bruna drycken, och jag behöver tre koppar på morgonen för att komma igång. Jag sveper dessa innan klockan 10, sedan är min koffeinkvot uppfylld för dagen och jag dricker inget mer. Möjligen att jag tar en kopp på eftermiddagen, men det är mer bonus och inget jag behöver.

Steg två är alltid att kolla mailen. Hur dagen utvecklar sig beror nästan alltid på hur inkorgen ser ut. Idag fick jag en förfrågan från en kund om att plocka fram exempelfiler från en integration, samt undersöka om integrationens logik kan återanvändas i ett annat flöde. Eftersom detta var en ganska liten uppgift tog jag mig an den på en gång och hämtade filerna från ett filarkiv där de sparas, och började sedan analysera integrationen. Den består av ett SSIS-paket (SQL Server Integration Services) som exekverar bat-filer och genom att läsa dessa blev min slutsats att de inte går att återanvända, men för säkerhets skull har jag dubbelkollat det med Douglas, så vi får se om jag hade rätt eller fel gällande det…

Efter att jag skickat svar på mailet var det dags att fortsätta med den lite större uppgiften jag har just nu, nämligen att utöka en integration med ett nytt flöde så att vi kan ta hand in filer i ytterligare ett format för en annan kund. Jag håller nu på att sätta upp miljön jag ska använda lokalt, och det krånglade en del i fredags. Vi har virtuella miljöer som vi arbetar i för det mesta, och någonting har hänt med min miljö – den har segat ihop totalt och ger mig kryptiska felmeddelanden. Jag hade förhoppningar om att det skulle lösa sig av sig själv under helgen, men det gjorde det såklart inte… Så istället för att fortsätta jobba har jag googlat felmeddelanden, ändrat lite inställningar och väntar just nu på att miljön ska starta om sig. Jag hoppas verkligen den fungerar som den ska nu, annars måste jag ringa till supporten och få hjälp.

I det här yrket är man väldigt beroende av sin dator, milt uttryckt. Utan fungerande dator är det i princip omöjligt att jobba, vilket gör sådana här problem jäkligt irriterande.. Det är visserligen bara en virtuell miljö som krånglar och inte hela datorn, så det kunde definitivt vara värre, men det är ändå frustrerande. Nu ska jag prova att starta upp miljön igen, fick en precis en idé om hur detta kan lösas, måste testa direkt…

Försenad fredagsblogg!

Jag började egentligen skriva det här inlägget i fredags, men arbetsveckan tog slut innan orden gjorde det, så jag återupptar inlägget sent denna måndagseftermiddag. Anledningen till att veckan tog slut fort i fredags är att jag var i Stockholm under dagen och arbetade hos mina kollegor mitt på Drottninggatan, för att sedan skriva en certifiering i SQL Server. Dagen började bra med en kaloristinn pepparkakslatte på Starbucks (måste ju passa på när en är i storstan) och sedan en lunch med Stockholmskollegorna på Kött- & Fiskbaren, ett mycket trevligt lunchställe precis runt hörnet från kontoret. Som vanligt var jag alldeles för upptagen med att äta för att komma ihåg att ta ett kort på maten, men Norge-kollegan Lena (som ni kommer få veta mer om senare i veckan) lyckades iaf ta en bild där jag och Johan sitter och arbetar hårt.

20151120_105149

Det var mycket trevligt att sitta på Stockholmskontoret och jobba en dag, men jag var som sagt inte bara där för nöjes skull, utan jag skrev även en certifiering i SQL Server.

Vadå certifiering?

Jag ska ta det från början: Microsoft erbjuder flera olika certifieringar inom de olika plattformarna och teknikerna de har, och som konsult är det väldigt bra att ha en sådan för att visa på pappret vilka kunskaper en har. Jag nämnde det i mitt tidigare inlägg när jag skrev om BizTalkkursen, när jag skulle skriva en certifiering som inte blev av, och jag bestämde mig ganska snart efter det för att skriva ett i databashantering istället, nämligen SQL Server. Själva titeln är MCSA (SQL Server), Microsoft Certified Solutions Associate, och den får man efter tre test med olika inriktning. I fredags klarade jag det första deltestet, Exam 70-461: Querying Microsoft SQL Server 2012, som fokuserar på själva utvecklarbiten av SQL Server – att skriva kod för att kommunicera med databasen helt enkelt.

Hur gör man då?

Det finns säkert flera olika vägar en kan gå för att skriva ett sådant här certifieringstest, men vi gör det genom bolaget Addskills, som även anordnar utbildningar inom olika områden. Det går att boka certifieringar via deras hemsida (men lär från mig och dubbelkolla med Microsoft så certifieringen fortfarande finns kvar…) och de verkar kosta från 1900 kr och uppåt. Jag åkte ut till deras lokaler i Kista (blå linje mot Akalla med tunnelbana, tar ca 20 min från centralen) och väl där måste man skriva in sig, visa legitimation, bli fotograferad, läsa igenom massor av regler och lämna ifrån sig alla sina tillhörigheter. Utom kläderna på kroppen då. Som tur är. He. Därefter följer en testadministratör med en in i ett litet rum där det finns små bås med datorer och administratören berättar att det finns en filmkamera i taket och att testet är övervakat. Sedan är det bara att klicka på en startknapp på skärmen och testet är igång!

Var det svårt?

Ärligt talat…. Ja. Det var faktiskt sjukt svårt. När jag var mitt inne i testet var jag nära att ge upp. Eller, jag hade redan gett upp hoppet och tänkte att det här går aaaaaaaldrig, med min allra gnälligaste röst. Men uppenbarligen hade jag lite mer flyt än jag trodde, för när testet var klart så var jag faktiskt godkänd (även om det var på håret…). Direkt när testet är klart så visas resultatet på skärmen, så ingen nervös väntan på något resultat i flera dagar eller veckor.

Vad ska jag tänka på om jag tar en certifiering?

I samband med att en skriver testet så förbinder en sig att inte berätta något om innehållet eller frågorna, så jag kan inte ge några specifika råd, men jag har några tips som jag tror kan vara bra att ha med sig:

  • Plugga! Det finns en hel del böcker kring de olika certifieringarna, sök på certifieringsnumret på ex Adlibris så kommer du säkert hitta något. En del går bara igenom teorin, men andra kommer med tips och råd kring hur själva examinationen går till.
  • Gör gärna olika förberedande test, men lita inte på att de speglar det riktiga testet! Jag hade en skiva med övningsfrågor som var släppt av Microsoft själva, men inte heller det var speciellt likt the real deal.
  • Läs igenom informationen kring varje test så du vet vilka delar du behöver kunna!
  • Var beredd på de olika typerna av frågor som kan komma. Här finns en lista på de olika frågeformaten.
  • Se till att vara mätt och utvilad! Det är inte tillåtet att ta med mat in i testsalen, och även om vissa test har schemalagda pauser är det inte alla som har det. Jag hade ingen sådan paus, och om en isf väljer att ändå ta en så tickar klockan vidare under tiden. Jag brukar vara ganska snabb men hade inte haft tid att pausa.

Sådär, nu har jag lärt er allt jag kan (och får) om certifieringar! Fredagen slutade sedan med Klubb Katushka på Norrlands nation i Uppsala, men det mina vänner, är en helt annan historia. ;)

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: