« Hem

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!

 

 

Övergödd konsult

Vi brukar inte fika så ofta på kontoret och det är sällan det står godis framme hos oss. Men när det väl kommer fram något gott, då slås det på stort. I måndags morse möttes jag av nedanstående syn:

20160307_095333Sofia, vår fantastiska administratör och alltiallo, höll på att packa typ 10 påskägg fyllda med godis till våra kunder. Och det var ju inga små ägg om en säger så! Här snackar vi mängder mätta i kilo och inte hekto. Som tur är, vilket både jag och diverse kollegor fick erfara, tejpade hon igen alla äggen till kunderna. Antagligen förstod hon vilken risk det är att förvara sådana mängder sötsaker i närheten av ett gäng gottegrisar…

Jag var rätt lättad över att de var igentejpade, då behöver jag inte kämpa emot suget utan vet att det är oåtkomligt. Men så i går visade Sofia att det fanns godis kvar i ett av skåpen! Givetvis smög jag dit och undersökte vad som fanns kvar: en kombo av gräddkola, geisha och mars-bars i tre lådor. Icke ihoptejpade… Ska ta ett kort nästa vecka och se hur mkt som försvunnit.

20160310_080340Imorse visade jag mitt godisfynd för Micke, min skrivbordskollega mittemot, som blev föga imponerad. Han visade istället det enorma ägg som vi ska ha på kontoret, som låg undangömt i ett annat skåp! Jag undersökte såklart även detta med godisexpertens öga och nedan ser ni att jag ger mitt godkännande. Notera också hur liten min hand är jämfört med ägget… Och då är det här kortet ändå taget från kortsidan av det. Hittade även varsitt ägg till oss anställda i en påse på chefens kontor*. Kommer rulla fram efter påsk…

20160310_092902Hmm, hoppas jag inte har förstört nåns överraskning nu… Vi kommer alltså få en del godis till påsk.

*OBS – inte så att jag snokade! Men vrider jag huvudet ca 120 grader åt vänster så ser jag rakt in i ena hörnet på chefens kontor, och där stod påsarna helt öppet. Vrider jag mig 180 grader ser jag hela kontoret. (Det är glasväggar..)

Att plugga eller inte plugga, är det frågan?

Jag pluggade väldigt länge innan jag började jobba. Först läste jag litteraturvetenskap, sedan pluggade jag på komvux och blev undersköterska, och därefter halkade jag in på IT-området. Totalt har jag läst ca 6 år på universitetet och det är min studieskuld som får CSN att gå runt. Ekonomiskt är det väldigt osmart att plugga länge – många av de jag har pluggat med nöjde sig med en tvåårig högskoleexamen och började jobba direkt. För mig, som tog en masterexamen, är det tre år där jag samlade på mig mer skulder istället för att tjäna pengar.

När jag tänker tillbaks och funderar på varför jag ändå gjorde det valet, så slår det mig att jag inte har någon annan anledning än att jag helt enkelt ville plugga. Jag gillar att plugga och visste dessutom att detta var sista gången i mitt liv som jag skulle göra det på heltid, och då ville jag göra det rejält, även om det rent logiskt inte lönar sig. Systemvetenskapliga programmet på masternivå är dessutom mer forskningsförberedande än praktiskt inriktat, så det handlade inte heller om att fördjupa programmeringskunskaperna, även om utbildningen gav mer förståelse för hur IT fungerar på ett övergripande plan när det införs i olika verksamheter.

Just IT-utbildningar är dessutom lite speciella. Det är en bransch där allt händer väldigt snabbt och nya tekniker hinner skapas, hypas, peaka och bli omoderna på ungefär en vecka. Ofta säger man att typ 50 % av det man lärt sig i skolan är föråldrat när man börjar jobba, och det är ju en ganska nedslående siffra. En sjuksköterska eller läkare har troligtvis inte samma problem – kroppen ser likadan ut nu som för tio år sedan, även om utveckling såklart sker inom vården också.

Jag tycker mig ofta se ett lätt förakt mot utbildning inom den här branschen, och ofta får studenter tips att göra egna projekt vid sidan av plugget, för att visa vad de kan, som om själva utbildningen inte vore nog. Programmering ses som ett ”kall”, något man gjort sedan barnsben och brunnit för hela livet. Den självlärda programmeraren hyllas, den skollärda ses som lite mindre värd. Många spyr galla över hur efter utbildningen är jämfört med branschen i stort, och att det man lär sig i skolbänken knappt är relevant för hur verkligheten fungerar. Jag vet, för jag har varit en av dem som gnällt…

Men, nu när jag är färdig och ser tillbaks på skolan, så skulle jag vilja slå ett slag för plugget! Visst, det finns en massa snubbar (för det är oftast snubbar..) som är självlärda programmerare sen barnsben och väldigt duktiga på det de gör. Förutom att arbetsgivare gärna ser att man har kunskapen på papper, så kommer en utbildning ge dig en stabil plattform att stå på och du kommer ha väl befästa grundkunskaper som du kan bygga vidare på. Ett exempel: känner en sån här snubbe som är grym på relationsdatabaser – men han visste inte vad första normalformen innebar eller varför den är viktig att följa… Ni som läst databasteknik vet vad jag menar.

Jag tror starkt på att ha en rejäl examen i bagaget, det ser snyggt ut på CV-t och det är något du alltid har med dig. Visst, ibland är det svårt att se ljuset i tunneln och det känns som att allt man gör är att läsa och man har alltid något hängande över sig. Men jag lovar – tiden går fort och det kommer vara värt det i slutänden!

Language: