Varför får vi dubbletter när en integration försöker igen?

Samma sak två gånger

Ni har en koppling mellan två system. En dag upptäcker någon att samma kund ligger dubbelt, eller att en faktura bokförts två gånger. Ingen har gjort fel för hand. Orsaken är nästan alltid att något försökte igen.

Nätverk och system fallerar ibland. Ett anrop tar för lång tid, tjänsten svarar inte, eller svaret kommer aldrig fram fast arbetet blev gjort. En bra koppling försöker då igen, och det är rätt. Men om ett andra försök skapar en andra post har ni byggt in en dubblett.

Vad idempotens betyder

Ordet är krångligt men idén enkel: en operation är idempotent om den ger samma resultat oavsett hur många gånger den körs. ”Sätt kundens status till aktiv” kan köras tio gånger utan skada. ”Lägg till en faktura” kan inte det, om ingenting säger att fakturan redan lagts till.

Fyra sätt att bygga det

1. Ge varje operation en nyckel

Vid varje anrop som skapar något skickas en unik nyckel med, till exempel ett id för kvittot eller ordern. Tar mottagaren emot samma nyckel igen vet den att det redan är gjort, och svarar med det ursprungliga resultatet i stället för att göra om det.

2. Låt databasen vägra dubbletter

Lägg en unik regel på det som inte får finnas två av, till exempel organisationsnummer för bolag eller ett externt id för en faktura. Då stoppar databasen dubbletten även om koden har en miss.

3. Uppdatera om det finns, skapa annars

Många system har ”upsert”: skapa posten, men om en med samma nyckel redan finns, uppdatera den. Det passar synkroniseringar, där samma post kommer många gånger.

4. Håll ordning på status

Spara för varje jobb om det är väntande, pågående, klart eller misslyckat. Då vet ni vad som behöver köras om, och ni undviker att två processer tar samma jobb.

Så försöker man igen på ett bra sätt

• Vänta längre för varje försök. Hamra inte på en tjänst som redan har problem.
• Sätt en gräns. Efter några försök ska jobbet markeras som misslyckat och någon ska få veta det.
• Skilj på fel som går att försöka om och fel som inte gör det. Fel inloggning blir inte rätt vid nästa försök.

Det syns särskilt i bokföring

Dubbletter i bokföring är dyra att reda ut. Se Hur kopplar man Fortnox till ett eget system eller en AI-agent? för vad som bör finnas före en sådan koppling.

Och med AI-agenter

En agent kan anropa samma verktyg flera gånger, eftersom modellen försöker igen när svaret verkar oklart. Verktyg som skapar saker bör därför vara byggda så att ett andra anrop inte skapar en andra post. Se Hur ser ett bra MCP-verktyg ut?.

Kontrollfrågor till er egen koppling

• Vad händer om samma meddelande kommer två gånger?
• Finns det en unik regel i databasen för det som inte får vara dubbelt?
• Vad händer efter att ett jobb misslyckats, och vem får veta?
• Kan ni köra om en hel period utan att få dubbletter?

Mer om valet av kopplingstyp finns i API, webhook eller filexport.

Har ni en koppling som ger dubbletter? Hör av er.