Verwerk een volledige route-update als een gevalideerde momentopname en bescherm ieder afgeleid veld tegen oudere gebeurtenissen. Een later ontvangen losse ETA- of statusupdate kan inhoudelijk ouder zijn dan de routesnapshot. Zonder versiecontrole kan een bezorgstop teruggaan van geleverd naar onderweg of kan een oude route opnieuw als actueel verschijnen.
Een routewebhook bevat samenhang
Een route is niet alleen een lijst losse stops. Voertuig, volgorde, geplande datum en stopidentiteiten vormen samen de planning. Controleer daarom eerst of de snapshot bij de juiste werkruimte, route en datum hoort en of alle records geldig zijn. Pas daarna projecteer je de relevante velden naar lokale bezorgstops of het ERP.
Een volledige snapshot mag ontbrekende stops niet zonder meer als verwijderd behandelen. Bepaal of de provider werkelijk een complete autoritatieve route stuurde en of de lokale route nog dezelfde versie is. Verwijdering of ontkoppeling is alleen veilig wanneer de ontvangen route aantoonbaar de huidige route vertegenwoordigt.
Gebruik een klok per veld
Eén algemene “laatst bijgewerkt”-tijd is te grof. Status, ETA, voertuig en ritvolgorde kunnen uit verschillende gebeurtenissen komen. Bewaar daarom per relevant veld welke providergebeurtenis of versie het laatst is toegepast. Een nieuwere ETA mag de actuele aankomstverwachting wijzigen zonder een oudere status te herstellen; een geleverd-status mag niet verdwijnen doordat later een verouderde routesnapshot aankomt.
| Veld | Waarschijnlijke bron | Bescherm tegen |
|---|---|---|
| Status | Stop- of orderevent | Oudere routeprojectie |
| ETA | Live route-event | Verouderde schatting |
| Voertuig | Volledige route | Snapshot van vorige planning |
| Volgorde | Volledige route | Partiële update zonder context |
Deze projectie kan deel uitmaken van een configureerbare stroom in Connect.
Fictief voorbeeld: geleverd wordt niet teruggedraaid
Fictief voorbeeld: route R-18 wordt om 15:10 vernieuwd; stop 7 krijgt voertuig Bus 2 en positie 4. Om 15:42 meldt een stop-event dat order 9087 is geleverd. Door netwerkvertraging arriveert om 15:50 nog een routesnapshot die om 15:30 is gemaakt en de stop als onderweg toont.
De integratie gebruikt de snapshot nog wel voor velden waarvoor zij nieuw genoeg is, maar vergelijkt de statusklok. “Geleverd” van 15:42 blijft staan. De oudere snapshot maakt de stop niet opnieuw actief. Zou een volledig nieuwe route van 16:00 de stop aantoonbaar naar een ander voertuig verplaatsen, dan kunnen voertuig en volgorde wel veranderen volgens hun eigen versies. Dit fictieve voorbeeld maakt duidelijk waarom één recordtijd onvoldoende is.
Controlelijst voor routeprojectie
- Valideer werkruimte, route-ID, datum en providerhandtekening vóór verwerking.
- Bepaal expliciet of de payload volledig of gedeeltelijk is.
- Gebruik exacte stop- en orderidentiteiten; match niet op adres alleen.
- Bewaar versie of gebeurtenistijd per veranderlijk veld.
- Verwijder een lokale routekoppeling alleen als de snapshot autoritatief en actueel is.
- Maak overgeslagen oudere waarden zichtbaar in het technische auditspoor.
- Test gebeurtenissen bewust buiten volgorde.
In Desk hoort de medewerker de actuele bezorgtoestand te zien, niet iedere interne projectiebeslissing. Bij onderzoek moet wel herleidbaar zijn welke bron en versie het veld bepaalde. Meer over operationele samenhang tussen systemen staat bij maatwerksoftware voor processen.
Voer een chaos-test uit met dezelfde reeks gebeurtenissen in verschillende volgordes. Start met een routesnapshot, stuur daarna een ETA, een geleverd-event en tenslotte nogmaals de oude snapshot. Herhaal de test met de oude snapshot vóór het geleverd-event. De uiteindelijke zichtbare toestand moet in beide gevallen gelijk zijn. Controleer daarnaast dat een nieuw voertuig wel kan worden toegepast zonder de definitieve leverstatus terug te zetten. Hiermee bewijs je dat de projectie op inhoudelijke versies steunt en niet toevallig op de timing van de testserver.
Maak tenslotte een scheiding tussen operationele correctie en broncorrectie. Een medewerker kan lokaal zien dat een stop onjuist is, maar een lokale overschrijving die bij de volgende routewebhook verdwijnt geeft schijnzekerheid. Bepaal per veld waar correctie hoort: in routeplanning, in de webshop of via een gecontroleerde serviceactie. Toon bij een lokaal alleen-lezen veld een link of instructie naar de juiste bron, zodat het team geen tijdelijke workaround als permanente oplossing gebruikt.
Leg bij iedere handmatige correctie vast welke bron daarna opnieuw moet worden gelezen. Anders blijft het scherm tijdelijk juist, maar keert de oude providerwaarheid bij het volgende event terug.
Wil je routewebhooks bestand maken tegen dubbele en vertraagde events? Bespreek jouw status- en versieklokken met Yindle.