Hindre dobbeltbokføring når en API-forespørsel gjentas

Et nettverksbrudd kan skjule at et regnskapssystem allerede har opprettet et bilag. Integrasjonen ser ingen kvittering og sender samme grunnlag igjen. Idempotens betyr at gjentakelsen får samme tilsiktede virkning, uten at den økonomiske hendelsen registreres en gang til. HTTP-metoden alene dokumenterer ikke hvordan en konkret bilagsoperasjon fungerer.

Syntetisk eksempel med to forsøk

En lokal integrasjon skal registrere et kjøpsgrunnlag på 4 800 kroner. Identifikatoren «kjop-A17» er oppdiktet og betegner samme forretningshendelse i begge forsøkene.

Uten gjenkjennelse kan de to første forsøkene gi 9 600 kroner i registrerte kjøp. Et felt med samme bilagsbeskrivelse er ingen sikker sperre: to virkelige kjøp kan ha identisk beskrivelse og beløp.

Avtal nøkkelens levetid og innhold

Spør leverandøren om skriveoperasjonen støtter en dokumentert idempotensnøkkel, en ekstern referanse med entydighetskontroll eller en annen mekanisme. Stripe beskriver sin egen idempotensordning; dette er et konkret leverandøreksempel, ikke dokumentasjon på at et regnskaps-API tilbyr samme ordning.

Lagre nøkkelen før første sending. Knytt den til selskap, operasjonstype og det godkjente grunnlaget. Når beløpet endres, må integrasjonen skille en korrigering fra en nettverksretry. Samme nøkkel med annet innhold bør føre til en avklaring, ikke stille erstatning av et tidligere bilag.

Avklar også hva som skjer etter utløpt lagringstid. En leverandør kan slutte å huske nøkkelen, mens avsenderens gamle jobb fortsatt kan bli kjørt. Integrasjonens egen leveranselogikk må da hindre at historiske hendelser sendes som nye.

Prøv før skriveadgang åpnes

1. Send identisk syntetisk grunnlag to ganger og kontroller antall bilag.
2. Gjenta samme nøkkel med endret beløp og dokumenter responsen.
3. Prøv samtidige forsøk, ikke bare to sendinger etter hverandre.
4. Kontroller om returverdien peker på det opprinnelige bilaget.

Velg automatisk gjentakelse først når resultatet kan etterprøves i mottakeren. Dersom nøkkelstøtte mangler, bruk en kontrollert oppslags- og avklaringsrutine; beløpssøk alene er for svakt. Ved samarbeid med Aiak kan avstemmingsansvaret avklares som del av regnskapsarbeidet, mens API-leverandøren må dokumentere den tekniske mekanismen.

En lokal sperre må også tåle to arbeidere som starter samtidig. Dersom begge leser «ikke behandlet» før noen lagrer resultatet, kan de begge sende. Prøven bør derfor undersøke samtidighet og lagring av nøkkel som én kontrollert beslutning.

Se også ukjent resultat etter tidsavbrudd.