Message events
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.
FLOWX.AI works with the following message events nodes:
- Message Throw Intermediate Event
- Message Catch Boundary Event
- Message Catch Intermediate Event
- Message Catch Start Event
Message Throw Intermediate eventโ
This event throws a message and continues with the process flow. It enables the sending of a message to a unique destination.
ยปMessage Throw Intermediate EventMessage Catch Boundary eventโ
This type of event can be triggered at any time while the associated task is being performed. For an interrupting event, when the message is received, the user task is finished, and the token advances in the process flow. For a non-interrupting event, the user task to which the event is attached is not finished immediately when messages are received. Multiple non-interrupting events can be received while the token is still active in the user task.
ยปMessage Catch Boundary EventMessage Catch Intermediate eventโ
This event waits for a message to be caught before continuing with the process flow.
ยปMessage Catch Intermediate EventMessage Catch Start eventโ
This event starts an instance after receiving a message. The correlation key is optional, and if an instance with the same correlation key exists, a new process instance is not created.
ยปMessage Catch Start EventMessage 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).
A correlation key is a key that can have the same value across multiple instances, and it is used to match instances based on their shared value. It is not important what the attribute's name is (even though we map based on this attribute), but rather the value itself when performing the matching between instances.
For example, in an onboarding process for a user, you hold a unique personal identification number (SSN), and someone else needs a portion of your process, specifically the value of your input (SSN).
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 eventsmessageName
: a unique name at the database level, should be the same for throw and catch eventscorrelationKey
: a process variable used to uniquely identify the instance to which the message is sentdata
: allows defining the JSON message body mapping as output and input
Data exampleโ
{
"document":{
"documentId": "${document.id}",
"documentUrl": "${document.url}"
}
}