Designing Workflows

The process automation component gives control over which actions to perform and when. While this can significantly improve performance it does put more emphasis on the design of the workflows.

Prioritize events

While not always applicable, events are the most granular change drivers. They result in the least latency and cause very little overhead. This is why these should always be preferred over other triggers where possible.

The workflow below shows how events can be used to manage a lot of common use-cases. This state-machine depicts a dataElement which may only be processed once some validation passes. The validation will first be triggered OnCreate. If validation succeeds it will become 'Ready', otherwise it will revert to 'Created'. Validate is then only re-run if the element is modified, causing the OnModify trigger to fire. The OnTransition trigger ensures Process is started as soon as the element is transitioned to 'Ready'.

Note how this workflow doesn't require any timers to operate, but will still catch all moments of change instantly.

Scheduled task execution

Events won't cover all possible use-cases, especially with time as a change driver. Some tasks may need to run periodically to act on external changes, or some elements may simply need to wait for a certain timestamp before progressing. For these type of tasks we introduced the Schedule trigger. It is specific to a single transition and utilizes a cron-like syntax to define when it should run.

For more information on how to configure these see the triggers page.

Workflow priority

With the workflow model, a priority can be configured using the workflow.priority option. This can be applied to both workflows and transitions. The default priority for all workflows is 50, higher is more important.

Assigning a priority to the workflow itself will change its priority over other workflows. This can be useful if some tasks are more important to execute quickly than others. Priority can also be used to create a more 'greedy' execution order, by giving the first transition a lower priority than the rest of the transitions.

Transition recovery

It can happen a transition didn't complete correctly, which means it is stuck in its interim state. To remedy this the process automation component will perform a recovery on elements stuck in an interim state. If the transition defines a recovery state it will move the element to this state. Otherwise, it will move to the failed state.

Providing task context

There are several ways to adjust the context of any running transition/task. Process automation will provide a net.democritus.processautomation.context.WorkflowProcessingContext for any transition that runs. This can be used to make the distinction between parts of the code executed by a workflow or through any other cause.

Additionally, there are two options on transitions to modify the context:

Option

executeTask.implementation Transition

Select the implementation of the task that should be used. Will be added to the BasicProcessingContext. If no implementation is specified, the default implementation will be used.

<options>
  <executeTask.implementation>secure</executeTask.implementation>
</options>

Option

executeTask.context.user ComponentWorkflowTransitionCascading

Specify the username of the user who should be added to the UserContext when running a transition.

<options>
  <executeTask.context.user>workflow</executeTask.context.user>
</options>

Preventing infinite loops

The OnTransition trigger can cause a hot-loop when defined on a transition where one of the end-states is also the begin-state. To prevent this behavior the transition.noSelfLoop option can be used by defining it on the trigger.

Option

transition.noSelfLoop WorkflowOnTransitionCascading

Prevent the transition to be triggered repeatedly by a self-loop (where begin-state equals end-state).

<options>
  <transition.noSelfLoop/>
</options>