Webhooks och ERP: undvik dubbla order
Skilj på händelse och order. Ett exempel tar upp upprepningar, samtidiga leveranser och ett förlorat ERP-svar.
Planera upprepade meddelanden som ett normalt villkor för din butikskoppling. En webhook är ett HTTP-meddelande som avsändarsystemet startar. Om bekräftelsen uteblir kan meddelandet komma igen. Det får inte skapa en extra ERP-order.
Stripe beskriver upprepade händelser och möjligheten till separata händelser om samma objekt. Kontrollera den verkliga avsändarens regler. Exemplet här är fiktivt och beskriver inte Stripes API.
Två identifierare med olika uppgifter
Butiken shop-1 har order W-240. Händelsen evt-17 meddelar att den skapats. ERP-systemet ger den koden E-901. Med händelseidentifieraren känns en upprepad leverans igen; butik och order identifierar tillsammans affärshändelsen. En senare evt-18 kan meddela en ändring av samma order.
Meddelande eller fel | Förväntat resultat |
|---|---|
Första evt-17 | Skapa E-901 i ERP och koppla den till W-240. |
Upprepad evt-17 | Känn igen den befintliga åtgärden; ingen extra order. |
Två samtidiga kopior av evt-17 | En unikhetsregel tillåter bara en bearbetningsuppgift. |
evt-18 för W-240 | Koppla ändringen till befintlig order och pröva ändringsreglerna. |
ERP skapar ordern men svaret försvinner | Utfallet är först oklart; stäm av med samma identitet innan ett nytt försök att skapa ordern. |
Spara mottagandet varaktigt
Kontrollera först meddelandets äkthet enligt avsändarens metod. Spara sedan händelsen varaktigt innan du bekräftar mottagandet. En unikhetsregel för avsändare och händelse förhindrar separata uppgifter för samtidiga kopior. Enbart en sökning före infogning räcker inte vid samtidighet.
Den fortsatta bearbetningen måste utgå tillförlitligt från den varaktiga lagringen. En bakgrundsprocess kan ta över sparade, väntande händelser. Åtgärden kan då hittas även efter en krasch mellan mottagande och bearbetning.
Ett möjligt svar efter lagringen:
{
"eventId": "evt-17",
"orderId": "W-240",
"status": "queued"
}Exemplet använder HTTP-status 202. Svaret bekräftar att händelsen tagits emot för bearbetning, inte en ERP-order. Kan varaktigt mottagande inte säkerställas ska mottagaren inte rapportera framgång.
Skydda även ERP-anropet mot upprepning
Använd en stabil nyckel för att skapa ordern, exempelvis shop-1:W-240:create, om målsystemet stöder det. Behåll nyckeln vid ett säkert nytt försök. Stripe visar principen för sitt eget API; exakt betydelse och lagringstid beror på målsystemet.
Utan stödet krävs en annan tillförlitlig koppling: exempelvis en extern orderkod vars unikhet säkerställs i målsystemet och möjlighet att hämta utfallet. Är skapandet oklart efter timeout får åtgärden vänta på avstämning. En ny slumpmässig kod skulle få upprepningen att se ut som en ny order.
Händelselagring och ERP-skapande i två system utgör inte automatiskt en gemensam transaktion. Håll mottagande, bearbetning, oklart utfall och bekräftat slut åtskilda. I exemplet är skapandet klart först när kopplingen till E-901 bekräftats.
Ta med fel i acceptanstestet
Skicka evt-17 igen i följd och samtidigt. Bryt svaret efter ett lyckat skapande i ERP. Prova sedan evt-18 som en verklig ändring. Förvänta en enda skapad order, bevarad koppling och synlig avstämningsstatus vid okänt utfall. Bestäm också hur länge identifierarna måste sparas för möjliga upprepningar.
Källor
Läs vidare
Alla artiklar
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade