Message Flows
Let Pools of One Model Talk to Each Other
Message Flows
A BPMN collaboration draws several pools in one diagram. Each pool is its own process. A message flow (dashed arrow) connects two pools: a message throw event in one pool sends a message, a message catch event in the other pool waits for it.
Flower runs all pools of the collaboration in one process instance. The message flow is delivered inside the engine, no web service and no Jira Automation is involved.
What works
| Element | Role in a message flow |
|---|---|
| Intermediate throw event with a message definition | sends |
| Message end event | sends |
| Intermediate catch event with a message definition | receives |
| Boundary event with a message definition | receives |
| Start event with a message definition | receives |
A throw event with a message flow sends its message to the other pool. A throw event without a message flow keeps its usual meaning: a web service call or a Jira Automation event.
When the process instance ends
The process instance is resolved when the last pool has ended, not when the first one does. A pool that has reached its end event waits for the others. A terminate end event ends the whole process instance at once and closes the open work items of all pools.
A pool that is never started (for example a pool with a message start event whose message is never sent) keeps the process instance open.
Pools without a process
A message flow to or from a black box pool (a pool without a process, for example the customer) is documentation only. Flower ignores it.
Validator
The validator of the editor warns (yellow, the model can still be published) about a message flow that the engine cannot deliver, for example one between two tasks: MESSAGE_FLOW_NOT_DELIVERED.