Overview

Message events serve as a means to incorporate messaging capabilities into business process modeling. These events are specifically designed to capture the interaction between different process participants by referencing messages.

By leveraging message events, processes can pause their execution until the expected messages are received, enabling effective coordination and communication between various system components.

​

Intermediate events

​

Boundary events

Boundary Events involve handling by first consuming the event occurrence. Message Catch Boundary Events, triggered by incoming messages, can be configured as either interrupting or non-interrupting.

​

Intermediate vs boundary

Intermediate Events

• Intermediate events temporarily halt the process instance, awaiting a message.

Boundary Interrupting Events

• These events can only be triggered while the token is active within the parent node.

• Upon activation, the parent node concludes, and the token progresses based on the boundary flow.

Boundary Non-Interrupting Events

• Similar to interrupting events, non-interrupting events can only be triggered while the token is active in the parent node.
• Upon triggering, the parent node remains active, and a new token is generated to execute the boundary flow concurrently.

FLOWX.AI works with the following message events nodes:

• Message catch start event
• Message intermediate events
• Message catch boundary event

​

Message events correlation

Messages are not sent directly to process instances. Instead, message correlation is achieved through message subscriptions, which consist of the message name and the correlation key (also referred to as the correlation value).

The communication works as follows: you receive a message on a Kafka topic - ${kafka.topic.naming.prefix}.core.message.event.process${kafka.topic.naming.suffix}. The engine listens here and writes the response.

​

Message events configuration

• attachedTo: a property that applies to boundary events
• messageName: a unique name at the database level, should be the same for throw and catch events
• correlationKey: a process variable used to uniquely identify the instance to which the message is sent
• data: allows defining the JSON message body mapping as output and input

​

Data example

{
	"document":{
			"documentId": "${document.id}",
			"documentUrl": "${document.url}"
	}
}