Webhooks zijn geschikt wanneer een webshopgebeurtenis snel verwerkt moet worden; geplande synchronisatie is geschikt voor periodieke controle, grotere datasets en bronnen zonder betrouwbare events. Een robuuste e-commercekoppeling gebruikt vaak beide. Orders kunnen direct via een webhook starten, terwijl voorraad of een reconciliatieproces volgens schema loopt.
De keuze “realtime of batch” is dus geen geloofskwestie. Maak haar per gegevensstroom op basis van bedrijfsimpact, volume, bronmogelijkheden en herstelbaarheid.
Wat een webhook wel en niet doet
Een webhook meldt dat er iets is gebeurd, bijvoorbeeld dat een WooCommerce-order is aangemaakt of bijgewerkt. De ontvangende integratie valideert het bericht, bepaalt of het relevant is en legt het vast voor verwerking. De webhook zelf hoeft niet het hele orderproces uit te voeren.
Volgens de officiële WooCommerce-documentatie over webhooks kunnen onder meer wijzigingen aan orders, producten en klanten een bericht starten. Dat een platform zo’n onderwerp aanbiedt, betekent nog niet dat ieder event voor jouw proces relevant is; die selectie blijft een functionele ontwerpkeuze.
Dat laatste is belangrijk. Als een webshop tijdens het webhookverzoek moet wachten op AFAS, een vervoerder en een betaalprovider, wordt de ontvangst kwetsbaar. Eén trage externe dienst kan leiden tot een time-out en een herhaald bericht. Laat het ontvangstpunt daarom snel antwoorden nadat het bericht veilig is geaccepteerd en plaats de vervolgstappen in een duurzame wachtrij.
Webhooks passen goed bij
- nieuwe of betaalde orders die snel naar administratie of fulfilment moeten;
- statuswijzigingen met directe betekenis voor klant of medewerker;
- bezorg- en retourgebeurtenissen van logistieke systemen;
- wijzigingen waarbij alleen het betrokken object verwerkt hoeft te worden.
Wanneer een planning sterker is
Een geplande synchronisatie vraagt op vaste momenten welke gegevens nieuw of gewijzigd zijn. Dit is bruikbaar voor grote of veranderlijke datasets, voor bronnen die geen volledig eventmodel hebben en voor processen waarbij enige vertraging acceptabel is.
Voorraadupdates kunnen bijvoorbeeld periodiek gewijzigde AFAS-artikelen ophalen. Een nachtelijke of vaker lopende reconciliatie kan daarnaast controleren of alle webshoporders uiteindelijk een administratieve tegenhanger hebben. Zo’n controle vindt gaten die door een gemist webhookbericht, tijdelijke configuratiefout of handmatige ingreep zijn ontstaan.
Geplande synchronisatie past goed bij
- catalogus- en voorraaddata die efficiënt in batches wordt gelezen;
- periodieke controles tussen bron en doel;
- historisch herstel of een eerste volledige synchronisatie;
- processen zonder betrouwbaar webhookmechanisme.
Vergelijk de twee mechanismen
| Vraag | Webhook | Planning |
|---|---|---|
| Snelheid | Verwerkt kort na gebeurtenis | Afhankelijk van interval |
| Belasting | Gericht per event | Efficiënt voor batches, maar kan veel lezen |
| Gemiste wijziging | Mogelijk zonder vangnet | Kan wijzigingen opnieuw opvragen |
| Piekgedrag | Wachtrij moet pieken opvangen | Run kan worden gedoseerd |
| Herstel | Event opnieuw verwerken | Per periode of object herhalen |
Filter voordat je werk veroorzaakt
Niet iedere orderupdate vraagt een volledige synchronisatie. WooCommerce kan meerdere updates rond één aankoop produceren. Filter op relevante orderstatussen en gebeurtenissen, en voeg korte, samenhangende updates zo nodig samen. Bewaar wel voldoende informatie om de uiteindelijke staat correct te verwerken.
Vermijd daarnaast een echo: systeem A wijzigt systeem B, waarna B een event terugstuurt dat A opnieuw laat schrijven. Maak vastgelegde bronidentiteit, eventidentiteit en eigen mutaties herkenbaar. Anders kan een op het oog kleine statuswijziging een eindeloze of kostbare keten starten.
Ontwerp herstel vanaf het begin
Voor beide mechanismen geldt dat een mislukte verwerking niet verloren mag gaan. Classificeer fouten: een time-out kan opnieuw worden geprobeerd, een ontbrekende productmapping vraagt een medewerker en een ongeldig bericht moet zichtbaar worden afgewezen. Bewaar per stap wat ontvangen, besloten en uitgevoerd is.
Maak ook achterstand zichtbaar. Een wachtrij waarin alle berichten uiteindelijk worden verwerkt, kan operationeel toch falen als orders uren blijven liggen. Monitor daarom niet alleen foutaantallen, maar ook de leeftijd van het oudste onverwerkte bericht en de tijd sinds de laatste succesvolle broncontrole.
Een praktisch besliskader
- Beschrijf hoe snel de bedrijfsuitkomst nodig is.
- Controleer of de bron betrouwbare en voldoende gedetailleerde events levert.
- Bepaal of dezelfde gebeurtenis veilig opnieuw kan worden verwerkt.
- Ontwerp de wachtrij en foutafhandeling vóór livegang.
- Voeg een periodieke volledigheidscontrole toe voor kritieke stromen.
Een concreet orderproces staat in WooCommerce koppelen met AFAS. Het bredere ontwerp van een herstelbare keten lees je in webshop en ERP betrouwbaar koppelen. Yindle Connect combineert events, geplande verwerking, mapping en beheer in één integratielaag.
Testscenario’s voor beide routes
Test een webhook niet alleen met één handmatig bericht. Stuur hetzelfde event tweemaal, lever een oudere update na een nieuwere, laat de ontvanger tijdelijk falen en controleer wat WooCommerce met mislukte aflevering doet. De documentatie vermeldt dat webhooks na herhaalde mislukte afleveringen kunnen worden uitgeschakeld; monitoring moet zo’n stilgevallen bron dus actief vinden.
Test bij een geplande synchronisatie een lege run, een grote reeks wijzigingen, een run die halverwege stopt en twee runs die elkaar overlappen. Controleer of de volgende run verdergaat zonder reeds bevestigde resultaten onnodig opnieuw te schrijven.
Veelgestelde vragen
Is iedere vijf minuten synchroniseren bijna realtime?
Voor sommige processen is dat snel genoeg, maar het blijft een interval met mogelijke piekbelasting en een maximale vertraging. Beschrijf de bedrijfsbehoefte in plaats van het mechanisme “realtime” te noemen. Meet bovendien hoe lang verwerking ná het ophalen nog duurt.
Kunnen webhooks een periodieke controle vervangen?
Niet voor kritieke volledigheid. Webhooks zijn een sterke primaire trigger, maar configuratie, aflevering en verwerking kunnen ieder falen. Een aparte reconciliatie vergelijkt uiteindelijk gerealiseerde bedrijfsresultaten en vindt ook fouten die geen technisch alarm veroorzaakten.
Wanneer is een batch handiger?
Wanneer veel gelijksoortige records efficiënt samen kunnen worden gelezen, onmiddellijke verwerking niet nodig is of de bron alleen wijzigingsselecties biedt. Doseer de batch, bewaar voortgang en voorkom dat één ongeldig record de volledige reeks blokkeert.
Twijfel je welke delen realtime moeten en waar een planning verstandiger is? Laat Yindle één waardestroom met je uittekenen, inclusief gebeurtenissen, controles en herstelpad.