Signals & messages
Wat zijn signals en/of messages?
Signals of messages zijn specifieke berichten die je kan verzenden en ontvangen. Dit kan zowel binnen de scope van het applicatie alsook erbuiten. Zowel een signal als een message bestaan uit een key en een payload.
Use case
De belangrijkste use case is het opzetten van asynchrone en ontkoppelde communicatie tussen verschillende processen binnen één en dezelfde applicatie en/of met externe systemen. Klik hier om kennis te maken met enkele concrete voorbeelden.
Verschil message en signal
Het verschil tussen een signal en een message is dat je een signal uitstuurt over alle procesinstanties binnen je applicatie heen. Elk procesinstantie die luistert, zal het signaal oppikken en daarop reageren. Vergelijk het met een uitzending op radio waar iedereen naar kan luisteren. Een message stuur je daarentegen uit naar één of meerdere concrete procesinstanties die je moet specifiëren. Vergelijk het met een telefoon- of een chatgesprek tussen twee of meerdere mensen.
Let op: een signal heeft een maximaal bereik. De potentiële impact is dus veel groter dan bij het uitsturen van een message. Hou daar rekening mee tijdens het configureren.
Uitsturen van een message of signal
Via een expressie
Je kan een message of signaal uitsturen via de runtime service die je aanroept via een specifieke expressie. Deze kan je definiëren via een send task, een service taak of een listener. Dit kan in principe op eender welk BPMN-element.
Message
Basisexpressie waarmee je een message kan uitsturen binnen één en hetzelfde proces.
${runtimeService.createMessageCorrelation('myMessage').processInstanceBusinessKey(execution.processBusinessKey).correlate()}
Deze expressie kan je aanmaken via de workflow expressiebouwer in Studio.
Optioneel kan je ook variabelen meesturen.
${runtimeService.createMessageCorrelation('myMessage').processInstanceBusinessKey(execution.processBusinessKey).setVariable("variableName", "value").correlate()}
Je kan een message uitsturen naar een andere procesinstantie. In onderstaande expressie verwijzen we naar een process instance id die opgeslagen zit in een de variabele ‘dossierId’ (op zijn beurt weer ingevuld door de variabele ‘selectedDossier’).
${execution.getProcessEngineServices().getRuntimeService().createMessageCorrelation("myMessage").processInstanceVariableEquals("dossierId", selectedDossier).correlate()}
Signal
Basisexpressie waarmee je een signaal kan uitsturen over alle procesinstanties in de applicatie heen.
${runtimeService.createSignalEvent("mySignal").send()}
Optioneel kan je ook variabelen meesturen.
${runtimeService.createSignalEvent("mySignal").setVariable("variableName", "value").send()}
Tip: deze expressies kan je ook aanmaken met de hulp van een AI-chatbot zoals ChatGPT.
Via template (signaal)
Specifiek voor een intermediate signal throw event is er een template voorzien die achter de schermen automatisch een signal aanmaakt. Binnen deze template kan je vervolgens aanduiden of je dit signaal wil omzetten naar een mijlpaal en/of doorsturen naar DOSIS.
Opvangen van een message of signal
Message
Een message kan je opvangen via een message catch event of task binnen de BPMN-workflow. Dit kan een losstaand, apart element zijn binnen de workflow, maar het kan ook een boundary event zijn (zie voorbeeld 4 onderaan de pagina). Opgelet: het opvangen van en reageren op een bericht (message) gebeurt enkel als er een process token aan het wachten is op dat bericht (message).
Message intermediate catch event: algemene info en specifieke eigenschappen.
Message receive task: algemene info en specifieke eigenschappen.
Signal
Een signal kan je opvangen via een signal intermediate catch event binnen de BPMN-workflow. Dit kan een losstaand, apart element zijn binnen de workflow, maar het kan ook als boundary event. Opgelet: het opvangen van en reageren op een bericht (signal) gebeurt enkel als er een process token aan het wachten is op dat bericht (signal).
Signal intermediate catch event: algemene info en specifieke eigenschappen.
Voorbeelden
Voorbeeld 1 (message): interactie tussen twee processen
Een typisch voorbeeld is de interactie tussen een ordersysteem en een betalingssysteem. Zodra de klant zijn of haar bestelling geplaatst heeft, stuurt het ordersysteem een message naar het betalingssysteem. Daar wordt een apart proces opgestart waardoor de klant een betaalverzoek krijgt. Ondertussen gaat het proces binnen het ordersysteem verder. Verschillende stappen komen aan bod zoals het checken van de voorraad, de opmaak van een picking order, het opstellen van de factuur, enzovoort. Uiteindelijk wacht het orderproces enkel nog op een bevestigingsbericht van het betalingssysteem om over te gaan tot de laatste stap, typisch de levering van het order aan de klant.
Het voorbeeld toont duidelijk hoe beide processen onafhankelijk van elkaar bestaan (ontkoppeld), waardoor ze elk hun eigen tempo en timing volgen (asynchroon). Dit biedt veel meer flexibiliteit dan dat alles in één proces gedefinieerd zit.
Kleine kanttekening: het betalingssysteem werkt hier ook op basis van een BPMN-workflow, maar dit hoeft niet noodzakelijk zo te zijn. Het kan evengoed een extern systeem zijn dat volledig losstaat van je applicatie en dat op basis van een compleet andere technologie werkt. In dat geval kunnen berichten overgebracht worden door een message broker.
Voorbeeld 2 (signal): aanmaak mijlpalen
Een tweede voorbeeld is het aanmaken van mijlpalen door middel van intermediate signal throw events. Hiermee kan je de dossierstatus visualiseren zowel binnen de backoffice (in te stellen via de dossiertype overzichtsvelden functionaliteit) als binnen de frontoffice (in te stellen via de dossiertype instellingen).
Dit toont hoe je via uitgestuurde signalen een backend functie binnen de applicatie kan triggeren.
Voorbeeld 3 (message): bulktaken functionaliteit
Een derde voorbeeld betreft de bulktaken functionaliteit. Hier zetten we een ‘one-to-many’ relatie op tussen enerzijds een goedkeuringsproces en anderzijds een hele lijst van processen waar je de goedkeuring naartoe moet sturen. Concreet kan je met onderstaande setup gelijkaardige handelingen over meerdere dossiers heen in één enkele actie uitvoeren.
Dit zorgt voor een verhoogd gebruiksgemak voor de goedkeurder. In plaats van elk proces afzonderlijk te moeten openen en elke individuele goedkeuringstaak uit te voeren, volstaat hij of zij nu met een goedkeuringsproces op te starten en via een selectietaak de dossiers uit te kiezen waar goedkeuring verleend mag worden. Ook hier blijken opnieuw de voordelen van ontkoppeling en asynchroniciteit.
Voorbeeld 4 (messsage): automatisch afsluiten van optionele taken
In dit voorbeeld is er via CMMN een optionele actie gedefinieerd binnen het proces. Deze actie mag slechts tijdelijk beschikbaar zijn voor de gebruiker. Van zodra het proces een bepaald stadium bereikt, wordt de optionele actie afgesloten en verwijderd. Ook hier verloopt dit via een bericht dat uitgestuurd en opgevangen wordt.
Dit toont een nuttige toepassing van messages binnen één en hetzelfde proces.
Meer info
Meer info over message events op de Camunda 7 documentatiesite.
Meer info over signal events op de Camunda 7 documentatiesite.