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 have long been missing from our applications. 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.