Integrationer & systemkopplingar

De flesta webbprojekt vi gör innehåller minst en integration, och det är oftast där komplexiteten sitter. Här är hur vi jobbar med det, och vad som brukar gå fel.

Vilka system kopplar vi ihop?

Det beror på verksamheten, men mönstret är detsamma: någonstans finns sanningen, och webben ska spegla den utan att någon matar in saker två gånger.

Tre exempel ur riktiga projekt:

Sjöräddningssällskapet

Larmhändelser registreras i systemet Daedalos. Vi mappade upp vad som fanns där, avgjorde vad som behövde synkas till webben, och byggde flödet i etapper – först larmrapporteringen, sedan de frivilliga sjöräddarna, sist båtarna. Larmen passerar skräddarsydda filter innan de når webbplatsen, där ett redaktionellt team granskar dem innan publicering.

Göteborgs Universitet

Avancerade integrationer från flera av universitetets IT-system, bland annat kurser och program, in i en gemensam Drupal-plattform. Arbetet krävde påbyggnadsmoduler som bidragit tillbaka till Drupals kodkärna.

Ebeco

Installatörssök via Google Maps Platform API, och kontaktuppgifter som hämtas direkt från tjänsten Garantera i stället för att administreras manuellt. Resultatet är att ingen behöver hålla en lista uppdaterad.

Betalflöden

Klarna, Adyen, Swedbank Pay, Swish och kortinlösen kopplas in som vilken integration som helst – men med hårdare krav på felhantering, eftersom ett flöde som tappar en order kostar pengar direkt. Själva betalningen sker hos leverantören; det vi bygger är vägen dit och tillbaka, och det som händer när något går fel på halva vägen.

Vad brukar gå fel?

Sällan själva kopplingen. Nästan alltid något av det här:

• Ingen äger datamodellen. Två system kallar samma sak olika saker, och ingen har bestämt vilket som gäller. Det är ett verksamhetsbeslut, inte ett tekniskt, och det går inte att koda sig förbi.
• Motpartens API är sämre än utlovat. Dokumentationen beskriver något annat än det som faktiskt svarar, eller så finns inget API alls utan en nattlig filexport.
• Datakvaliteten. En integration gör inte dålig data bra. Den gör den snabbare tillgänglig på fler ställen.
• Ingen har bestämt vad som händer när det går sönder. Ett flöde som fungerar 99 procent av tiden behöver en plan för den sista procenten – larm, loggar och någon som tittar på dem.

Hur börjar ett integrationsuppdrag?

Med att kartlägga vad som faktiskt finns. I Sjöräddningsprojektet var första steget att gå igenom informationen i det befintliga systemet och avgöra vad som skulle sparas, synkas eller lämnas kvar.

Det låter självklart. Det hoppas ändå över regelbundet, och det är då integrationer blir dubbelt så dyra som beräknat.

Vi bygger oftast direkt mot motpartens API med autentiserad åtkomst. Det ger färre rörliga delar att förvalta och en felsökning som stannar mellan två system i stället för tre. När flödena är fler eller mer komplicerade än så bygger vi ett mellanlager – och finns det redan en integrationsplattform hos er jobbar vi i den.

Vem äger integrationen sen?

Vi, om ni vill det. En integration är inte klar när den fungerar första gången – motparten uppdaterar sitt API, certifikat går ut, dataformat ändras. Det hör hemma i ett förvaltningsavtal, inte i ett projekt som avslutas.