Message Event
Message Start Event
In descriptive models, a Message start event indicates a process initiated by external request, where the request is described by the incoming message flow.
In executable models, it is more common to use a None start event for processes initiated by external request, and represent the request payload as data inputs. However, it is possible to use a Message start event to instantiate the process upon receipt of a message flow, particularly when the message is sent by a modeled external process or service.
Catching Message Intermediate Event
A catching Message intermediate event with sequence flow in and out means wait for an incoming message flow, then resume. The event creates a resume point for the process. This event has the same behavior as a Receive task, but since Workflow Modeler does not currently support Receive tasks in Automation, you need to use a catching Message event.
Throwing Message Intermediate event
A throwing Message intermediate event is the same as a Send task. When the sequence flow arrives, it automaticlly sends an outgoing message flow and immediately continues.
Message Boundary Event
A Message boundary event initiates an exception flow if a message flow is received while the activity is running. It may be either interrupting or non-interrupting.
Event Configuration
The Attributes/Message Event action presents athe dialog below to enter attributes from the spec but which are not required for automation. The important attribute for automation is the datatype, selected by clicking Attributes/Data Type. If a Message is defined for the event, its datatype must match that of the Message event.
To use the payload of an incoming message flow in the process logic, it must be passed to a data object through a data output mapping, accessed via the Attributes/Data Mapping context menu action.
Message Correlation
A Message event is not triggered by all incoming messages, just those matching defined message correlation parameters, set using the Attributes/Message Correlation context menu action. Correlation is defined by up to three filters, specified in the dialog below:
The filters are applied in order, first Filter 1, then Filter 2, then Filter 3, but it is not necessary to use all three. Message correlation uses publish-subscribe integration. The sender of the message does not need to know what processes or process instances are subscribing to (i.e., listening for) the message. Each filter is a FEEL Boolean expression of message payload data (as captured by the Message event) and other process variables.
Filter 1 is an expression of Message event data, i.e. the message payload itself. If the expression is true, the event is triggered; if false, not triggered. If the filter is blank, it is true by default. Filter 1 matches any instance of a particular process.
Filter 2 uses process instance tags to select a particular instance of the process. A process instance tag is a user-defined string that ideally matches a single process instance. For example, if the process is handling an Order with a particular id, you need to create a process instance tag unique to that instance, such as "Order " + Order info.id. To add it, right-click in the process diagram, Attributes/Process Instance Tags, insert the tag expression and click Add.
Now to handle a subsequent cancellation message for that particular Order, you can use Filter 2 to define a FEEL Text expression of Message event data. If an expression of event data components matches a process instance tag, the event is triggered. For example, if the Cancellation message contains component OrderID, the Filter 2 expression "Order " + OrderID will trigger the event only in the matching instance.
Filter 3 is the most powerful, as it is a Boolean expression of process instance data. However, performance can be slow unless the count of instances is reduced by applying Filters 1 and/or 2 first.