Webhooks en ERP: dubbele orders voorkomen
Scheid gebeurtenis en order. Een uitgewerkt voorbeeld behandelt herhalingen, gelijktijdige ontvangst en een verloren ERP-antwoord.
Plan herhaalde meldingen als normaal onderdeel van uw winkelkoppeling. Een webhook is een HTTP-bericht dat het verzendende systeem start. Blijft bevestiging uit, dan kan het opnieuw binnenkomen. Dat mag geen extra ERP-order opleveren.
Stripe beschrijft herhaalde gebeurtenissen en mogelijke afzonderlijke gebeurtenissen over hetzelfde object. Controleer de regels van uw werkelijke afzender. Het volgende voorbeeld is fictief en beschrijft geen Stripe-API.
Twee codes met verschillende taken
Winkel shop-1 heeft order W-240. Gebeurtenis evt-17 meldt de aanmaak. Het ERP kent E-901 toe. De gebeurteniscode herkent herhaalde aflevering; winkel en order identificeren samen de bedrijfshandeling. Een latere evt-18 kan een wijziging van dezelfde order melden.
Bericht of fout | Verwacht resultaat |
|---|---|
Eerste evt-17 | ERP-order E-901 maken en aan W-240 koppelen. |
Herhaalde evt-17 | Bestaande handeling herkennen; geen extra order. |
Twee gelijktijdige exemplaren van evt-17 | Een uniciteitsregel laat maar één verwerkingstaak ontstaan. |
evt-18 voor W-240 | Wijziging aan bestaande order koppelen en volgens wijzigingsregels beoordelen. |
ERP maakt de order, maar het antwoord verdwijnt | Uitkomst eerst onzeker; met dezelfde identiteit afstemmen vóór opnieuw aanmaken. |
Ontvangst duurzaam opslaan
Verifieer eerst de echtheid van het bericht volgens de methode van de afzender. Sla daarna de gebeurtenis duurzaam op voordat u ontvangst bevestigt. Een uniciteitsregel op afzender en gebeurteniscode voorkomt aparte taken voor gelijktijdige kopieën. Alleen zoeken vóór opslaan is bij gelijktijdigheid onvoldoende.
De verdere verwerking moet betrouwbaar uit deze duurzame opslag volgen. Een achtergrondproces kan opgeslagen, openstaande gebeurtenissen oppakken. De handeling blijft dan vindbaar na een crash tussen ontvangst en verwerking.
Een mogelijk antwoord na opslag:
{
"eventId": "evt-17",
"orderId": "W-240",
"status": "queued"
}Dit voorbeeld gebruikt HTTP-status 202. Die bevestigt opname in de verwerking; er is nog geen ERP-orderbevestiging. Kan duurzame opname niet worden verzekerd, dan mag de ontvanger geen succesvolle ontvangst melden.
Bescherm ook de ERP-aanroep tegen herhaling
Gebruik een vaste aanmaaksleutel zoals shop-1:W-240:create als de bestemming dat ondersteunt. Houd die gelijk bij een veilige herhaling. Stripe toont dit principe voor zijn eigen API; de precieze werking en bewaartermijn hangen van de bestemming af.
Zonder die ondersteuning is een andere betrouwbare koppeling nodig: bijvoorbeeld een extern ordernummer dat op de bestemming uniek wordt afgedwongen, met een opvraagmogelijkheid voor de uitkomst. Blijft na een timeout onzeker of de order is gemaakt, laat de handeling dan op afstemming wachten. Een nieuwe willekeurige code zou de herhaling als nieuwe aanmaak laten verschijnen.
Gebeurtenisopslag en ERP-aanmaak in twee systemen vormen niet vanzelf één transactie. Houd ontvangst, verwerking, onzekere uitkomst en bevestigd einde apart bij. In dit voorbeeld is aanmaak pas klaar na bevestiging van E-901.
Neem ook fouten mee in de acceptatie
Verstuur evt-17 opnieuw achter elkaar en gelijktijdig. Onderbreek het antwoord na geslaagde ERP-aanmaak. Probeer vervolgens evt-18 als echte wijziging. Verwacht één aanmaak, behoud van de koppeling en een zichtbare afstemmingsstatus bij een onbekende uitkomst. Bepaal ook hoelang de codes bewaard moeten blijven voor mogelijke herhalingen.
Bronnen
Verder lezen
Alle artikelen
Koppelingen & integratie met ASES
ERP, CRM en webshop netjes gekoppeld