Usage in BPMN and CMMN
This is an old version of the documentation for Flowable until version 3.13 and for the Angular-based Flowable Design 3.14/3.15. If you are running the latest version of Flowable please check out the current version of this page.
The BPMN palette in Flowable Design has following elements available:
- Event registry start: Starts a process instance when an event of a certain type is received.
- Event boundary event: Can be placed on any boundary of an activity (regular user tasks, subprocesses, etc.). Has the regular boundary event semantics, so can be used to interrupt the activity (or keep it active) when a certain event is received. Has the possibility for correlation parameter mapping to exactly specify which event should trigger which instance.
- Send event task: Used to send out an event over an outbound channel.
- Send and receive task: Used to send out an event and wait for another event in one step. This is an important construct documented below.
The CMMN palette in Flowable Design has following elements available:
- Case instance start: This option is a bit hidden away, due to CMMN not having a clear way of defining a start event like in BPMN. For this reason, it can be found when clicking on the case plan model. Starts a case instance when an event of a certain type is received.
- Event listener: Waits for an event to be received to occur.
- Send event task: Used to send out an event over an outbound channel
Send and Receive Task
A pattern that is used a lot is to send out and event, let some external service do something with this event and wait for a response back:
The problem is that a race condition can happen, when the service is very fast or when the database that Flowable uses is very slow. Flowable could still be processing the process or case instance and it's not yet in the state where the response event can be received (technically: the database transaction hasn't been committed yet).
The Send and receive task solves exactly that problem: it guarantees that no race conditions can happen when implementing this pattern.
Technically this is done using a combination of post-commit transaction listeners and async jobs on receiving the message to do this. This means that the send and receive tasks effectively behaves as a wait state, continuing the process instance asynchronously when the message is received.
