Webhooks og ERP: unngå doble ordrer

Planlegg gjentatte meldinger som et normalt vilkår for integrasjonen med nettbutikken din. En webhook er en HTTP-melding som avsendersystemet starter. Hvis bekreftelsen uteblir, kan meldingen komme igjen. Det skal ikke opprette en ekstra ERP-ordre.

Stripe beskriver gjentatte hendelser og muligheten for separate hendelser om samme objekt. Kontroller reglene til den faktiske avsenderen. Eksemplet her er fiktivt og beskriver ikke Stripes API.

To identifikatorer med ulike oppgaver

Butikken shop-1 har ordren W-240. Hendelsen evt-17 melder at den er opprettet. ERP-systemet gir den koden E-901. Hendelsesidentifikatoren gjenkjenner gjentatt levering; butikk og ordre identifiserer sammen forretningshandlingen. En senere evt-18 kan melde en endring i samme ordre.

Lagre mottaket varig

Kontroller først meldingens ekthet med avsenderens metode. Lagre deretter hendelsen varig før du bekrefter mottaket. En entydighetsregel for avsender og hendelse hindrer separate oppgaver for samtidige kopier. Et søk før innsetting alene er ikke nok ved samtidighet.

Videre behandling må følge pålitelig fra den varige lagringen. En bakgrunnsprosess kan overta lagrede, ventende hendelser. Handlingen kan dermed finnes igjen etter et avbrudd mellom mottak og behandling.

Et mulig svar etter lagringen:

{
  "eventId": "evt-17",
  "orderId": "W-240",
  "status": "queued"
}

Eksemplet bruker HTTP-status 202. Svaret bekrefter at meldingen er tatt inn til behandling, ikke en ERP-ordrebekreftelse. Hvis varig mottak ikke kan sikres, skal mottakeren ikke melde at det lyktes.

Beskytt også ERP-kallet mot gjentakelser

Bruk en stabil opprettelsesnøkkel som shop-1:W-240:create hvis målsystemet støtter det. Behold nøkkelen ved et sikkert nytt forsøk. Stripe viser prinsippet for sitt eget API; nøyaktig betydning og lagringstid avhenger av målsystemet.

Uten denne støtten trengs en annen pålitelig kobling: for eksempel en ekstern ordrekode med håndhevet entydighet i målsystemet og mulighet for å hente utfallet. Er opprettelsen uklar etter timeout, må handlingen vente på avstemming. En ny tilfeldig kode ville få gjentakelsen til å ligne en ny opprettelse.

Hendelseslagring og ERP-opprettelse i to systemer utgjør ikke automatisk én transaksjon. Hold mottak, behandling, uklart utfall og bekreftet avslutning atskilt. I eksemplet er opprettelsen ferdig først når koblingen til E-901 er bekreftet.

Ta med feil i godkjenningen

Send evt-17 på nytt etter hverandre og samtidig. Avbryt svaret etter vellykket ERP-opprettelse. Test deretter evt-18 som en reell endring. Forvent én opprettelse, bevart kobling og synlig avstemmingsstatus ved ukjent utfall. Bestem også hvor lenge identifikatorene må lagres for mulige gjentakelser.

Kilder

• Stripe: Receive events in your webhook endpoint

• Stripe: Idempotent requests