Triggers
The concept of triggers is introduced to have fine-grained control over the transitions in the workflow state-machine. Each transition can have a number of triggers, depending on the needs of your application.
CRUD Triggers
process automation Two crud-action triggers are supported currently;
OnCreate and OnModify. The OnCreate will only trigger once for a dataElement when it is created through its logic
Bean. The OnModify on the other hand will trigger every time an element is modified through the logic Bean. The event
information will contain the Details projection as presented in the logic layer.
Transition Trigger
process automation The OnTransition triggers for every element which is
transitioned by the process automation
component. It is primarily useful for a sequence of tasks which are executed autonomously.
DataCommand Trigger
process automation It is common for applications to transition based on a
user action or other external source. The ByDataCommand trigger makes it easy to trigger (a set of) transitions through
a command. Define a command on the target element with hasTargetInstance=true. This command can now be used as the target
of the trigger, and will expand the required implementation. Two options are defined on the DataCommand to customize behavior.
DataCommandWhen defined, the command will perform linked transitions in a blocking manner. The until_complete option
value indicates no timeout, while a positive integer indicates a timeout (in ms) for the transition to complete.
<options>
<workflow.trigger.blockingMs>until_complete</workflow.trigger.blockingMs>
</options>
<options>
<workflow.trigger.blockingMs>500</workflow.trigger.blockingMs>
</options>
Schedule Trigger
process automation The Schedule trigger allows for defining a schedule
using a cron-like syntax for each transition. The main difference with cron is that we also support a 'seconds' and
'year' property.
The following trigger configurations show some examples of what is possible with a schedule.
- every-10-seconds.xml
- bidaily-at-one.xml
- first-of-month-12-o-clock.xml
<trigger type="Workflows::Schedule" name="Every10Seconds">
<second>*/10</second>
<minute>*</minute>
<hour>*</hour>
</trigger>
<trigger type="Workflows::Schedule" name="BiDailyAtOne">
<hour>1,13</hour>
</trigger>
<trigger type="Workflows::Schedule" name="FirstOfMonth12oClock">
<hour>12</hour>
<dayOfMonth>1</dayOfMonth>
</trigger>
FlowEngine Trigger
Adding the FlowEngine trigger indicates the transition should be picked up by a FlowEngineBean. It corresponds directly
to a StateTask element in the database configuration. Each workflow in the model which has a linked
FlowElement also expands a <Workflow>ConfigureBean which will manage the available StateTasks in
the database on startup. Any changes to the model will simply be persisted when a new version of the application is
deployed. This means you no longer have to manually configure your database for the workflows when using the metamodel.
The database configuration has a lot of options, as documented here. In order to maintain compatability each of these options can be represented in the model as well.
ProcessAutomation
Instead of the ConfigureBean the options are directly used in the EngineBean. Additionally, all available settings are
configurable on the Workflow element instead of FlowElement. With processAutomation you can only configure waitTime,
batchSize and batchTimeout. Further configurations are defined elsewhere such as the Transition.
Options
WorkflowFlowElementConfigures the BATCH_TIMEOUT field on on EngineService. After
the specified timeout (in seconds) the currently active batch will be
cancelled if it is still busy. Defaults to 300s.
<options>
<flowEngine.engineService.batchTimeout>100</flowEngine.engineService.batchTimeout>
</options>