Webhookintegrationer behöver regler för upprepningar

När du planerar en webhookintegration bör upprepade leveranser behandlas som ett möjligt driftfall. Programvarubeslutet behöver hantera vad som händer med affärsåtgärden när meddelandet kommer en andra gång. En tillförlitlig anslutning besvarar inte ensam den frågan.

En förlorad signal gör utfallet osäkert

I en fiktiv kundportal utlöser ett meddelande att en order skapas i ERP-systemet. Ordern skapas, men svaret når inte avsändaren. Avsändaren skickar meddelandet igen. Om varje mottagning blint skapar en ny order blir resultatet två order från samma avsedda åtgärd.

Stripe anger uttryckligen att händelser kan levereras flera gånger. Det belägger ett konkret fall hos en leverantör. Vilka upprepningar din egen anslutning kan orsaka behöver du kontrollera utifrån dess kontrakt. En utebliven mottagningssignal innebär varken säker framgång eller säkert misslyckande.

Bedöm upprepningen utifrån affärseffekten

Den önskade regeln i exemplet är att samma meddelande kan hitta den redan skapade ordern i stället för att skapa ytterligare en. Integrationen behöver en avtalad identitet och en tillförlitlig koppling till bearbetningsresultatet. Skyddet måste även omfatta två kopior som kommer samtidigt; fristående steg med kontroll och senare lagring lämnar den frågan öppen.

Kontrollera i acceptansscenariot ordern i ERP-systemet, svaret på det nya försöket och den synliga statusen i portalen. En transportbekräftelse och en slutförd order kan vara olika tillstånd.

Insatsen beror på åtgärden

Om ett meddelande bara sätter ett visat värde till samma värde igen kan upprepningen vara oproblematisk. Att skapa en order eller en annan effekt som är avsedd en gång kräver mer skydd. Det innebär inte att varje liten anslutning måste få en extra kö.

Upprepningar bör förbli synliga. En ökning kan tyda på en störning. Vi rekommenderar att hantera förväntade upprepningar och samtidigt kunna undersöka ovanliga mönster.

Källor

• Stripe: Webhooks, duplicate events