Common patterns
Errors and exceptions
Catch a failure on the task where it happens, then retry, recover or end the process.
Model a failure as an error boundary event on the task that can fail. The exception path then either rejoins the main flow or ends in its own named end event.
process Nightly order import
lanes Operations | IT support
lane Operations
start:timer(R/P1D) Night started
xor #retry
service Import orders
on:error File rejected -> Check import file
service Update stock levels
end Orders imported
lane IT support
user Check import file
xor File can be fixed?
yes -> Fix import file
no (default) -> Import abandoned
user Fix import file
-> #retry
end:error Import abandonedWhat to notice
on:errorinterrupts Import orders: the import stops and the flow leaves through the event.- The retry loop points to
xor #retry, a merge in front of the task, not straight back to the task. - The path that gives up ends in its own end event, an error end event here, so the outcome is clear at a glance.
Other ways to handle an exception
- Notify and carry on. A non-interrupting event (
on~) starts a side path while the task keeps running. See Boundary events. - A customer withdraws. A message boundary event, such as
on:message Request withdrawn, stops the task when the message arrives. - Stop everything.
end:terminateends the whole process, including any parallel work still running.