Boundary Events
VidiFlow supports of the inclusion of boundary events in workflows. The following boundary events types are currently supported:
Message Boundary Event
Message Boundary Event (non-interrupting)
The usage of boundary events is explained in greater detail in the Step-by-Step Boundary Events section.
Message Boundary Event
Message Boundary Events can be triggered by tasks if an event occurs which prevents that task from being completed properly. The task will fail, but the boundary event can be employed to trigger a workflow branch for handling the event.
Interrupting boundary events are normally triggered in error cases. The task will cancel work and if a boundary event is modeled in the designer, the workflow path following that boundary event will be started only.
Message Boundary Event (Non Interrupting)
A non-interrupting Message Boundary Event can be triggered by a task before these are actually completed. As such, this type of boundary event is able to trigger a workflow branch which will be started in parallel, while the actual task is still in progress.
Non-interrupting boundary events may be used for showing some state change for starting parallel workflow branches. E.g. a transcoder might trigger a non-interrupting boundary event, when the transcoding of the file started. The branch following that event can start some work then on the growing file which is currently transcoded.
Error Boundary Event
Whenever an exception (unhandled error) is triggered inside a workflow task, one can handle those exceptions inside the workflow. The Workflow Designer now allows one to add an Error Boundary Event to any task for which error scenarios should be handled.
Without the Error Boundary Event, a task is canceled if an error occurs that is not handled by existing interrupting boundary events. This in turn would lead to the entire workflow being canceled.
Adding the event would be sufficient to handle the occurrence of errors. In addition, one can also add Error Code and Message Variables.
These variables will get the actual error code and message value as a value. Therefore, you can handle e.g. the message text in the tasks or rules.
Please note The error code will always have the value 0 (zero). There are no defined error codes for specific exceptions.