Op deze pagina
Een bijgewerkte bestelling komt binnen voordat de aanmaakgebeurtenis van die bestelling aankomt. Elders arriveert een betalingsgebeurtenis vóór een oudere abonnementsgebeurtenis. Dit zijn denkbeeldige teams met andere producten en gegevens. Beide kunnen geneigd zijn het probleem op te lossen door afleveringen op aankomsttijd te sorteren.
Dit is geen verslag van een incident bij een van die teams. De vraag is of de fouten dezelfde vorm hebben ondanks de verschillen tussen leveranciers.
Een opgenomen gesprek over wiskundige verbanden merkt op dat schijnbaar verschillende problemen een bruikbare gemeenschappelijke vorm kunnen hebben. Dat idee toepassen op software-integraties is een gevolgtrekking. Het wordt pas nuttig als de gedeelde vorm een test oplevert die door het gedocumenteerde gedrag van elk systeem wordt gedragen.
Haal de namen weg en leg de contracten terug
Beschrijf het eerste geval zonder productnamen: een gebeurtenis over een object kan na een latere wijziging van datzelfde object arriveren. Een ontvanger die aankomstvolgorde behandelt als statusvolgorde, kan nieuwe informatie overschrijven met oude.
Bekijk nu de echte contracten. De Shopify-documentatie voor webhooks zegt dat de volgorde zelfs binnen één onderwerp niet gegarandeerd is en geeft een voorbeeld waarin een productupdate vóór de aanmaakmelding kan worden bezorgd. De Stripe-documentatie voor webhooks garandeert ook geen aflevering in aanmaakvolgorde en raadt aan ontbrekende objecten op te halen als een eerder verwachte gebeurtenis nog niet is aangekomen.
Shopify en Stripe waarschuwen allebei dat aflevering niet op volgorde hoeft te gebeuren. De gemeenschappelijke vraag is of de eindtoestand klopt; identificaties en herstelregels vragen elk een eigen test.
De overdraagbare vraag is: ‘Als deze gebeurtenis eerder aankomt dan een verwante gebeurtenis, kunnen we dan nog steeds de juiste huidige status bepalen?’ Het technische antwoord kun je niet zomaar meenemen. Shopify beschrijft headers zoals X-Shopify-Webhook-Id en tijdstempels. Stripe gebruikt eigen gebeurtenis-ID’s en regels voor het ophalen van objecten. Een identificatie die in het ene systeem ‘aflevering’ betekent, hoeft in het andere niet hetzelfde aan te duiden.
Onze Brevo-connectorgids behandelt andere details over velden en toewijzingen. Die zijn belangrijk voor een werkende integratie, maar mogen niet als universeel API-gedrag gelden.
De gedeelde vorm is een voorwaarde die moet blijven gelden
Voor een klantsynchronisatie kan de voorwaarde zijn: na verwerking weerspiegelt het klantrecord in de bestemming de huidige status van de toegestane bron. Voor betalingen kan ze zijn: een actie die van betaling afhangt, gebeurt alleen wanneer de gezaghebbende betaalstatus dit toestaat. De voorwaarde benoemt wat waar moet blijven als gebeurtenissen laat, dubbel of onvolledig aankomen.
Schrijf vier dingen op voordat je een oplossing kiest:
| Vraag | Waarom het telt |
|---|---|
| Welke identiteit noemt het bedrijfsobject? | Een gebeurtenis-ID kan een bericht aanduiden in plaats van een klant of bestelling. |
| Welk systeem bezit de huidige status? | De gegevens kunnen een momentopname, wijziging of verwijzing zijn. |
| Welke timing garandeert de bron? | Aflevervolgorde hoeft geen statusvolgorde te zijn. |
| Welke eindvoorwaarde bewijst succes? | Ontvangst van een gebeurtenis bewijst geen juiste doeltoestand. |
De tabel helpt nadenken; ze is geen protocol. Het antwoord op de vraag naar de gezaghebbende bron hangt van de workflow af. Een actuele opvraag kan in het ene systeem nodig en in het andere ongeschikt zijn. Sommige gebeurtenissen moeten als historische feiten worden bewaard en niet opgaan in de nieuwste momentopname.
Hergebruik de test en pas de oplossing aan
Een kleine contracttest kan verwante gebeurtenissen in omgekeerde volgorde sturen en nagaan of de uiteindelijke doeltoestand correct blijft. Een andere kan dezelfde aflevering twee keer sturen. Deze tests tonen de vorm van het risico. De leveranciersdocumentatie bepaalt vervolgens hoe je elke gebeurtenis herkent, controleert en herstelt.
Dat onderscheid beschermt tegen knip-en-plakarchitectuur. Een sleutel voor ontdubbeling uit de ene API kan in een andere falen. Een tijdstempel met grove precisie kan de volgorde niet bewijzen. Het huidige object ophalen kan voor een statussynchronisatie nodig zijn, maar kan niet elke historische tussenstap reconstrueren. De gids voor meerdere bedrijfstools begint met de eigenaar van elk veld; zonder die keuze heeft ‘nieuwste’ geen heldere betekenis.
Het overdragen van patronen kent grenzen. Vergelijkbare symptomen kunnen verschillende oorzaken hebben: een ontbrekend record kan wijzen op een ongeoorloofde zoekopdracht, vertraagde webhook, ongeldige veldtoewijzing of geweigerde schrijfactie. Vergelijk het broncontract, doelcontract en de waargenomen eindvoorwaarde voordat je twee gevallen gelijk noemt. Verschilt er één, behoud dan de gedeelde vraag en verander de test.
De methode is ook buiten gebeurtenisaflevering nuttig. Een veld dat door een API wordt geaccepteerd maar niet in het zichtbare record verschijnt, roept bij elke connector dezelfde algemene vraag op: wat bewijst de bevestiging en welk bewijs toont de bedoelde toestand? Het antwoord kan bestaan uit het teruglezen van de bestemming, schemaonderzoek of een rechtencontrole. Het patroon zegt dat je transport van betekenis moet scheiden. Het zegt niet welk veld of endpoint je moet gebruiken. Die kleinere les is minder spectaculair dan een universeel recept, maar reist verder omdat de lokale feiten zichtbaar blijven.
De sterkste herbruikbare les is geen stukje afhandelingscode. Het is een vraag die de overstap naar een ander systeem overleeft en het plaatselijke contract makkelijker te onderzoeken maakt.
Veelgestelde vragen
Kun je dezelfde integratietest bij verschillende leveranciers gebruiken?
De vraag is vaak overdraagbaar, bijvoorbeeld of updates in een andere volgorde kunnen aankomen. Gebeurtenis-ID’s, betekenis van gegevens, handtekeningen en herstelstappen moeten uit het contract van elke leverancier komen.
Wat is het verschil tussen een patroon en een gekopieerde oplossing?
Een patroon benoemt de foutvoorwaarde en wat waar moet blijven. Een gekopieerde oplossing gaat zonder controle uit van dezelfde identificaties, volgorde en statusbetekenis in het tweede systeem.
Wat moet je controleren na het verwerken van een gebeurtenis?
Controleer de doeltoestand die de workflow vereist, niet alleen de ontvangst of HTTP-reactie. De eindvoorwaarde hangt af van het bedrijfsobject en de regel voor de gezaghebbende bron.