Een event vertelt wat er is gebeurd.

Een event is een vastgelegde gebeurtenis, zoals “zending vrijgegeven”. Een opdracht vraagt om een actie, zoals “geef zending vrij”. Dat verschil voorkomt verwarring over verantwoordelijkheid. Het WMS beoordeelt bijvoorbeeld of de pick compleet is en legt de vrijgave vast. Andere toepassingen mogen op dat feit reageren zonder opnieuw zelf de vrijgave te bepalen.

Kies een zakelijke naam met een duidelijke betekenis. “Order bijgewerkt” vertelt een transportplanner weinig. “Zending gereed voor planning” kan bruikbaarder zijn, mits duidelijk is of gewicht, laadadres en tijdvenster definitief zijn. Leg ook vast of een correctie een nieuwe gebeurtenis oplevert.

Event-driven betekent dat toepassingen reageren op zulke gebeurtenissen. Dat kan tussen afzonderlijke systemen, maar ook tussen onderdelen van één toepassing. Je hebt er niet automatisch een microservicesarchitectuur voor nodig. De architectuur van een WMS of TMS is een afzonderlijke keuze.

Kies waar wachten acceptabel is.

Een dashboard kan vaak even achterlopen op de laatste magazijnhandeling. De beslissing om de laatste beschikbare pallet toe te wijzen vraagt een andere afspraak. Bepaal per proces welke informatie direct bevestigd moet zijn en waar een volgende stap later mag plaatsvinden. Dat tijdelijk uiteenlopen van gegevens heet eventual consistency: systemen werken naar dezelfde afgesproken toestand toe.

Een wachtrij, of queue, kan berichten vasthouden totdat een ontvanger ze verwerkt. Daarmee hoeft een tijdelijke storing bij het klantportaal de vrijgave in het magazijn niet te blokkeren. Het werk verdwijnt echter niet; de achterstand moet beheersbaar blijven. Meet hoeveel berichten wachten én hoe oud het oudste onverwerkte bericht is.

Maak in de gebruikersinterface zichtbaar wat al is afgerond en wat nog volgt. “Gereed voor transport” is niet hetzelfde als “rit ingepland”. Bij annulering tijdens die tussenperiode is een expliciete herstelroute nodig, bijvoorbeeld het intrekken van een nog niet uitgevoerde transportopdracht.

Maak een gebeurtenis herkenbaar.

Gebruik een eigen gebeurtenis-ID, een verwijzing naar het bedrijfsobject en een vastgelegde berichtversie. Een fictief voorbeeld:

{
  "eventId": "evt-9031",
  "type": "ShipmentReleased",
  "schemaVersion": 1,
  "shipmentId": "SHP-1048-2",
  "shipmentVersion": 7
}

De gebeurtenis-ID blijft gelijk bij opnieuw afleveren. De zendingsversie helpt om wijzigingen aan dezelfde zending te ordenen. Beide hebben een andere functie dan een trace-ID waarmee je technische verwerking volgt. Voeg in een werkelijk contract ook de benodigde bedrijfsgegevens en context toe; dit voorbeeld toont alleen de identificatie.

Spreek af of een event alle relevante gegevens van dat moment bevat of alleen een verwijzing. Wanneer de ontvanger later de huidige zending ophaalt, kan die inmiddels veranderd zijn. Een melding van een historische vrijgave combineren met actuele gegevens is alleen correct als het proces dat toestaat.

Bewaar de wijziging en het te verzenden bericht samen.

Stel dat de vrijgave in de database wordt opgeslagen, waarna het systeem crasht vóór het bericht naar de transportplanning is gestuurd. Alleen de volgorde “opslaan, daarna versturen” laat hier een gat. Andersom kan de planning een vrijgave ontvangen die uiteindelijk niet in het WMS is vastgelegd.

Een transactional outbox pakt dit specifieke probleem aan. De toepassing bewaart de bedrijfswijziging en een klaarstaand bericht binnen dezelfde databasetransactie. Een afzonderlijk proces leest de vastgelegde berichten en verstuurt ze. Bij terugdraaien van de transactie ontstaat ook geen klaarstaand bericht.

De verzender kan na aflevering uitvallen voordat hij zijn eigen voortgang heeft opgeslagen. Het bericht kan daardoor opnieuw worden aangeboden. De ontvanger moet herhaling dus nog steeds herkennen en haar verwerking daarop inrichten. De outbox is geen algemene garantie dat iedere actie in alle gekoppelde systemen precies één keer plaatsvindt.

Beheer hoort bij dit ontwerp: bewaak vastgelopen verzendingen, regel opnieuw aanbieden en ruim pas op volgens de afgesproken bewaartermijn. Zonder controle op achterstand kan een keurige outboxtabel alsnog gevuld blijven terwijl planners informatie missen.

Bepaal wat er gebeurt als berichten anders aankomen.

In een fictieve situatie krijgt de planning eerst een annulering en daarna een vertraagde vrijgave van dezelfde zending. Verwerken op aankomsttijd zou een geannuleerde opdracht opnieuw actief kunnen maken. Een tijdstempel alleen is geen sluitende oplossing: systemen kunnen verschillende klokken hebben en berichten kunnen onderweg vertragen.

Leg de benodigde volgorde per bedrijfsobject vast. Een oplopende versie kan helpen, maar de herstelkeuze hangt af van het bericht. Bij volledige momentopnamen kan een oudere versie vaak worden overgeslagen. Bij veranderingen zoals “voeg twee pallets toe” mag je ontbrekende tussenstappen niet zomaar negeren. Dan moet de ontvanger wachten, ontbrekende gebeurtenissen ophalen of de toestand opnieuw afstemmen.

Zet blijvend onverwerkbare berichten apart met een reden en verantwoordelijke. Een zogenoemde dead-letter queue bewaart probleemgevallen, maar lost ze niet op. Laat herstel dezelfde controles doorlopen als de normale verwerking. Het opnieuw afspelen van berichten mag bijvoorbeeld geen tweede labelbestelling of dubbele klantmelding veroorzaken.

Begin met één duidelijke bedrijfsgebeurtenis.

Een directe API-koppeling kan voor een eenvoudige overdracht voldoende zijn. Events worden interessant wanneer meerdere afnemers onafhankelijk reageren, tijdelijke vertraging acceptabel is of pieken moeten worden opgevangen. Daar staan extra afspraken over beheer, berichtcontracten en herstel tegenover. Ontwerp die afweging vanuit het werk, niet vanuit de populariteit van een techniek.

Verwar events ook niet met event sourcing. Bij event sourcing vormt een geschiedenis van gebeurtenissen de basis om toestand te reconstrueren. Een toepassing kan prima events uitwisselen terwijl zij haar actuele orders en voorraad op een gebruikelijke manier opslaat.

Blade bouwt logistieke systemen en de verbindingen tussen magazijn, transport en administratie. Bespreek één gebeurtenis die nu te veel handwerk veroorzaakt. We bekijken welke informatie waar nodig is, welke vertraging acceptabel is en hoe de verwerking controleerbaar blijft. Voor het dagelijkse beheer sluit de gids over monitoring van logistieke software hierop aan.