« Hem

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

 

 

Back in business!

Jajemän, nu är både jag och bloggen tillbaks efter semestern! Jag jobbar första dagen idag efter en ledighet på drygt två veckor. Inte så mycket kan tyckas, men det känns som att jag varit borta länge! Så idag har jag gått runt lite såhär på kontoret:

Vad var det jag höll på med innan semestern? Vad skulle jag ta tag i nu? Och vad hade jag för lösenord nu igen?

Min semester i sommar har främst bestått av olika festivaler (Metallsvenskan, Sweden rock, Rockviken, Skogsröjet och Subkult för den som är nyfiken) och det har varit intensivt med att kolla på band och campa. Speciellt under sista festivalen nu i helgen, då temperaturen sjönk ner mot 6 grader på natten. BURR!

Det finns nog alltid en känsla av melankoli över skiftet mellan sommar och höst, semester och jobb, men i år känns det faktiskt inte speciellt jobbigt. Det tror jag är ett gott tecken, att även om det är lite tråkigt att semestern är över, så har jag ingen back-to-work-ångest. Jag minns ett tidigare jobb jag hade, då jag nästan grät första dagen på jobbet efter semestern eftersom det kändes så jobbigt och ångestfyllt. Inget sådant idag, bara som sagt en lätt förvirring över vad jag höll på med.

Något som underlättar är vi har otroligt mycket spännande projekt på gång under hösten, hos flera av våra kunder. Sommaren har varit ganska lugn på den fronten, men nu känns det att alla börjar vakna till liv. Sprintar planeras, projektplaner skapas, krav samlas in och möten genomförs. Det känns som att alla är taggade på att dra igång med en rivstart nu och det smittar av sig, vilket är en härlig känsla! Nu kör vi stenhårt fram till jul!

Åtta saker jag önskar att jag hade känt till innan jag började jobba

Pluggar du informatik och funderar vad du borde lära dig om du har tid över? Varsågod, här kommer en lista på verktyg och begrepp som jag verkligen önskar att jag hade varit mer bekant med innan jag började jobba!

SQL Server jobs

Det första jag grejade med som konsult på Integrationsbolaget var SQL Server, och jag kände mig hyfsat hemma på den planhalvan. (Hey, jag har ju faktiskt undervisat i ämnet..) Ändå satt jag som ett frågetecken när en kollega sa att det är ett ”SQL jobb” som sköter en viss funktionalitet. Det är alltså en aktivitet, ofta att exekvera en lagrad procedur, som körs enligt ett schema, allt ifrån var tredje minut till en gång i månaden. Så om du sitter med SQL Server, ta en titt på SQL Server Agent och Jobs i object explorern, då slipper du sitta som jag och se oförstående ut när du stöter på det på jobbet.

Capture kopiera

 

Virtuella maskiner

Jag var svagt bekant med begreppet virtuella maskiner tidigare, men jag hade absolut ingen praktisk erfarenhet av att använda det förrän jag började jobba. Och när jag gjorde det så insåg jag att det enda arbetsverktyget jag använder i min ”riktiga” dator är i princip mailen och skype, all utveckling sker i virtuella miljöer. Fördelen med dessa är att man kan förbereda och spara färdiga uppsättningar, ex en Windows 10 maskin med SQL Server och Visual studio förinstallerat, som man lätt kan sätta upp och sedan ta bort när den inte längre behövs.

Internet Information Services

Jag har svaga minnen av att vi använde IIS i C#-projektet nåt år för att skapa en web service, men jag minns också att det var jäkligt förvirrande, vilket det också fortsatte vara när jag sedan började jobba. IIS är en webserver som följer med Windows, och är du inte bekant med den eller begreppet web service så är det ett hett tips att läsa på lite om innan jobbet börjar.

Soap UI

Och när du ändå håller på och har satt upp en web service i IISen, så kan du passa på att använda det trevliga verktyget SoapUI för att testa tjänsten. Den genererar automatiskt ett request för webtjänsten och visar sedan responset snyggt och prydligt. (En parentes: det här programmet är bra, men ibland känns det lite ostabilt, så har du erfarenhet av liknande program får du gärna lämna en kommentar och tipsa mig!)

Scheduled tasks

På samma sätt som man kan schemalägga aktiviteter i SQL Server, kan man göra det i Windows. Det gör du enkelt genom att söka på Task Scheduler från startmenyn, och här kan du definiera saker som ska hända antingen vid en viss tidpunkt, eller kopplat till ett visst event. Vi använder detta på flera servrar för att ex. schemalägga triggers för olika integrationsflöden hos en av våra största kunder, men den absolut bästa användningen är den Douglas implementerade någon gång i våras, nämligen att fredagslåten drar igång automatiskt varje fredag kl 17.

Global Assembly Cache

När jag i början på karriären (jao, jag är fortfarande i början, men jag menar i början-början, typ första veckorna) så satt jag med en integration och skulle testa lite ändringar i den, men hur jag än gjorde så fick jag inte den nya funktionaliteten att fungera. Det var som att BizTalk inte fattade att jag hade gjort en uppdatering, och när jag frågade en kollega om råd så svarade han: ”Har du gaccat assemblyn?”. Jag gav då det intelligenta svaret ”Va?”, men har sedan dess bekantat mig lite mer med begreppet. GAC är, enkelt uttryckt, ett ställe där dll-er behöver ligga för att de ska vara åtkomliga från andra applikationer, ex BizTalk, och ibland måste man manuellt uppdatera dessa genom att använda kommandoverktyget gacutil. Jag vet inte hur mycket detta används utanför systemintegrationsområdet, men vi använder det dagligen och det är bra kunskap att ha med sig ut i arbetslivet tror jag.

Message Queue

Det här är en sak som jag inte har en aning om ifall det används i ”vanliga” system och applikationer, utanför området systemintegration, men återigen är detta något vi använder hela tiden. En message queue är precis som det låter en kö där man kan lägga meddelanden, dvs. data i olika format, ofta som xml. Det som gör kön speciell, till skillnad mot att bara lägga filerna i en folder någonstans, är att de garanterar FIFO, alltså First In First Out och används när man behöver garantera att filer skickas i rätt ordning.

DebugViewer

Sist, och kanske även minst på den här listan, kommer verktyget DebugViewer, som är otroligt trevligt när man vill debugga kod i en annan miljö än direkt i Visual Studio. Det är också väldigt enkelt att använda: i din C#-kod skriver du System.Diagnostics.Trace.WriteLine(”Valfri text”); och sedan kan du deploya koden till en server, och bara du har debugviewer installerat på servern så kommer dina meddelanden dyka upp i dess fönster.

dbgview

Det var allt för den här gången! Nu kommer jag och bloggen ta lite välbehövlig semester och återkommer i slutet på augusti. Önskar er alla en fortsatt trevlig sommar!

Lära sig programmera

Innan jag började på systemutvecklarbanan hade jag ingen tidigare erfarenhet av programmering. Det var ett helt nytt fält för mig, en undersköterska i hemvården som försökte komma på vad hon ville bli när hon blev stor. Det enda jag visste var att jag gillade att sitta framför datorn och göra de administrativa uppgifterna, så min första trevare gick mot rollen som läkarsekreterare och på ett bananskal halkade jag in på informatik.

Där öppnade sig fältet för systemutveckling först på en mer övergripande nivå (jag tror min första kurs gällde hur man skulle köpa in affärssystem eller nåt sånt, inte så intressant såhär i backspegeln…) och sedan började jag titta närmare på just rollen som programmerare. Ämnet programmering fascinerade mig väldigt, även om jag närmade mig det med oerhörd försiktighet. Jag vet inte hur många gånger jag googlade ”lära sig programmera” och ”lära sig koda”, både på svenska och engelska, och givetvis den stora frågan: vart ska jag börja någonstans? Vilket språk är bäst för nybörjare? Vilka kurser? Böcker eller videos?

Och jag fick såklart tusen olika svar, i tusen olika forumtrådar: Java är bäst att börja med, eftersom det är ett högnivåspråk. Det är också sämst att börja med, eftersom det inte är processornära programmering, det bästa för nybörjare är Assembler. Assembler är dock sämst för nybörjare eftersom det är ett lågnivåspråk, det bästa är C# eftersom det mer liknar våra naturliga språk. Men det suger också för att det snarare är ramverk och utvecklingsmiljö du lär dig, kör istället på C eller C++ – fast börja för allt i världen inte med de språken, för PEKARE är något otroligt svårt och du kommer gå in i väggen direkt och tröttna, börja istället med HTML, men det är inte programmering faktiskt, kör PHP, trots att det är sämst, Python är bäst, eller JavaScript, eller Ruby, eller Lisp, eller Haskell, osv osv i all oändlighet.

Alla dessa svaren fick mig att tveka och under lång tid gick jag bara fram och tillbaks framför inlärningströskeln, utan att våga ta ett steg mot den, för jag visste inte vilken ände jag skulle börja. Idag ser jag tillbaks och önskar att jag hade sagt till mig själv: det spelar ingen roll vart du börjar! Ta något! Vad som helst! Kom igång! För såhär är det: Programmering är svårt i början. Oavsett vilket språk du börjar med.

Det är ett nytt tankesätt och kräver en viss logik, men det är definitivt inte så svårt som en del vill få det att låta. Jag vill dock poängtera att det inte är så enkelt att lära sig. Det tar tid! Och i början kan det kännas helt omöjligt att förstå sig på, det är nya begrepp och en del saker verkar först helt ologiska. Alla som har suttit i lärositsen har nog slitit sitt hår och frågat: VARFÖR beter sig datorn på detta vis? It makes no sense!!

https://funixx.files.wordpress.com/2014/09/adn5xmm_460s.jpg?w=510

Bildkälla

Vad vill jag säga med det här då? Att programmering är frustrerande och svårt att lära sig? Jao, det är en del av poängen, men inte den största. Det jag vill är att ta dig som funderar på att lära dig programmering åt sidan och säga: kör på! Gör inte som jag, och fundera en evighet på i vilken ände du ska börja, utan kasta in dig i matchen direkt. Det kommer vara tufft i början, men när du väl kommer över den första tröskeln kommer det bli mycket, mycket enklare och ju snabbare du kastar upp dig på tröskeln, desto snabbare kommer du nå den där punkten när polletten trillar ner och allt börjar ”make sense”.

Om jag skulle komma med lite konkreta tips för hur du kommer igång så är nog mitt största att ta en strukturerad kurs och inte hoppa runt på måfå bland olika källor. Jag, som är en plugghäst av rang, rekommenderar definitivt universitetskurser eftersom dessa ofta går ganska djupt i ämnet, och för att du får ett kvitto på att du lärt dig något. Tro dock inte att du kommer lära dig programmering av en enda kurs, för så snabbt går det inte.

Min taktik när jag började plugga var att först läsa en grundkurs i programmering på 7,5 hp på distans, innan jag började på systemvetenskapliga programmet, som innehöll i princip samma kurs igen, fast med lite annan infallsvinkel. Detta gjorde att jag hade ett litet försprång under andra kursen, och kunde sätta grunderna ordentligt, vilket jag tror behövs om du aldrig programmerat tidigare.

Så, sluta fundera och sök en programmeringskurs! Var beredd på att det kommer vara tufft i början men att belöningen kommer, det blir lättare och det är också en otrolig tillfredsställande känsla att skriva kod som fungerar. Det ger en slags maktkänsla att faktiskt kunna få datorn att göra som man vill, även om det bara handlar om att skriva ut ”Hello World” på skärmen.

Och ett litet PS: låt inte tanken på matematik skrämma bort dig! För ärligt talat, även om många programmeringskurser kräver matte C (eller vad det heter numera, matte 3?) så är det faktiskt inte så mycket matte. Jag läste bara B-kursen på gymnasiet, och inte med några toppbetyg direkt, och jag har klarat mig bra ändå. Det fina med att läsa just informatik och systemvetenskapliga programmet är att de inte kräver någon högre matte innan.

Language: