Webhook-integrasjoner trenger regler for gjentatte leveranser

Når du planlegger en webhookintegrasjon, bør gjentatte leveringer behandles som et mulig driftstilfelle. Programvarebeslutningen må håndtere hva som skjer med forretningshandlingen når meldingen kommer en gang til. En pålitelig forbindelse besvarer ikke alene det spørsmålet.

Et mistet signal gjør utfallet usikkert

I en oppdiktet kundeportal utløser en melding ordreopprettelse i ERP-systemet. Ordren opprettes, men svaret når ikke avsenderen. Avsenderen sender meldingen på nytt. Hvis hvert mottak blindt oppretter en ny ordre, gir samme tilsiktede handling to ordrer.

Stripe opplyser eksplisitt at hendelser kan leveres flere ganger. Det dokumenterer et konkret tilfelle hos en leverandør. Hvilke gjentakelser din egen forbindelse kan skape, må du undersøke ut fra kontrakten. Et manglende mottakssignal innebærer verken sikker suksess eller sikker fiasko.

Vurder gjentakelsen ut fra forretningsvirkningen

I eksemplet er ønsket regel at samme melding kan finne den allerede opprettede ordren i stedet for å opprette enda en. Integrasjonen trenger en avtalt identitet og en pålitelig kobling til behandlingsresultatet. Beskyttelsen må også omfatte to kopier som kommer samtidig; uavhengige trinn med kontroll og senere lagring lar spørsmålet stå åpent.

Kontroller i akseptansescenarioet ordren i ERP-systemet, svaret på det nye forsøket og den synlige statusen i portalen. En transportbekreftelse og en fullført ordre kan være ulike tilstander.

Innsatsen avhenger av handlingen

Hvis en melding bare setter en vist verdi til samme verdi igjen, kan gjentakelsen være uproblematisk. Ordreopprettelse eller en annen virkning som er tilsiktet én gang, krever mer beskyttelse. Det innebærer ikke at hver liten forbindelse må få en ekstra kø.

Gjentakelser bør fortsatt være synlige. En økning kan tyde på en feil. Vi anbefaler å håndtere forventede gjentakelser og samtidig kunne undersøke uvanlige mønstre.

Kilder

• Stripe: Webhooks, duplicate events