API-integrationer: sex fel som kostar pengar
En integration som fungerar i test och krånglar i drift har nästan alltid ett av sex fel. De handlar inte om vilket API som används utan om hur systemet beter sig när något går fel: när mottagaren är nere, när samma meddelande kommer fram två gånger, eller när ett fält betyder olika saker i de två systemen.
1. Direktanrop utan kö
Ett direktanrop mellan två system fungerar tills det ena är nere, och då är transaktionen borta. Med en kö emellan läggs händelsen på lager, försöks om med ökande fördröjning och hamnar i en felkö om den till slut inte går igenom. Det är skillnaden mellan en integration som kräver passning och en som inte gör det.
2. Återförsök utan idempotens
Så fort ni lägger till återförsök kan samma meddelande komma fram två gånger. Om operationen inte är idempotent ger varje omkörning en dubblettorder. Lösningen är att mottagaren identifierar händelsen på en nyckel och ignorerar den om den redan behandlats. Det här är det dyraste felet i listan eftersom det upptäcks av kunden, inte av er.
3. Fältmappning som ingen granskat
Den faktiska svårigheten är sällan tekniken utan att fälten betyder olika saker i de två systemen. "Leveransdatum" kan vara utlovat, planerat eller faktiskt. Skriv mappningen som en tabell som verksamheten kan läsa och invända mot innan den blir kod. Det är billigare att rätta där än i produktion.
4. Ingen övervakning på tystnad
De flesta sätter larm på fel. Färre sätter larm på att inget händer. En integration som slutat köra helt ger inga felmeddelanden alls, och upptäcks när någon undrar var veckans ordrar tog vägen. Larma på att kön växer och på att det gått för lång tid sedan senaste lyckade körningen.
5. Realtid när samma dag hade räckt
Realtid åt båda håll är dyrt att bygga och dyrt att felsöka. Fråga vad som faktiskt händer om data är tio minuter gammal. Ofta ingenting. Stödjer systemet webhooks får ni realtid nästan gratis; gör det inte det, är schemalagd hämtning var femtonde minut nästan alltid tillräckligt och mycket enklare att resonera om.
6. Ingen plan för när formatet ändras
Det andra systemet kommer att uppdateras. Fält byter namn, blir valfria, försvinner. En integration som antar att svaret alltid ser likadant ut går sönder tyst och skriver fel data. Validera svaret mot en förväntad struktur och larma när den inte stämmer, i stället för att låta ett saknat fält bli en tom sträng i affärssystemet.
Vanliga frågor
Vårt affärssystem har inget API. Går det ändå att integrera?
Ofta ja, men på en lägre nivå. Saknas API går det att arbeta mot databasen direkt, mot fil- eller SFTP-export, eller mot en importfunktion i systemet. Det blir långsammare och mer skört än ett riktigt API, och den skörheten bör vara uttalad från start så att förväntningarna stämmer med vad som faktiskt går att lova.
Hur ofta bör data synkroniseras?
Stödjer systemet webhooks sker synkroniseringen inom sekunder från att något ändras. Gör det inte det blir det schemalagd hämtning, vanligen var femte till var sextionde minut. Fråga vad som faktiskt händer om data är tio minuter gammal; svaret är oftare "ingenting" än folk tror, och då är realtid en kostnad utan nytta.
Hur upptäcker vi att en integration slutat fungera?
Bara om ni larmar på tystnad. De flesta sätter larm på fel, men en integration som slutat köra helt ger inga felmeddelanden alls. Larma därför på att kön växer och på att det gått för lång tid sedan senaste lyckade körningen, annars upptäcks det när någon undrar var veckans ordrar tog vägen.
Mer inom samma område
Core Web Vitals 101: vad som faktiskt påverkar laddtiden
De tre måtten förklarade, vad som orsakar dåliga värden i praktiken, och varför ett cacheplugin sällan hjälper.
Byta plattform utan att tappa trafik: en checklista
Vad som faktiskt avgör om trafiken överlever en replattformering, i den ordning arbetet ska göras.
