Skip to main content

Architecture & Philosophy

To get a better understanding of the internals of the processAutomation component we will discuss the architecture in a bit more detail.

Process flow​

The general idea of the component isn't very difficult. The image below depicts the process flow on a high level.

  • Change Driver refers to something which requires action from our application. If nothing has changed, there is no reason for us to do any work. It is important to define what can drive change within our system. A few examples of this are time, user input, task execution or external messages.
  • Task Queue will be notified when one of our change drivers produces an event. This event may simply be time passing, but can also be the creation of a dataElement. In any case, we now have a change on which we can act. The task queue is used to collect all tasks which result from the events in our system.
  • Processing is responsible for distributing the available work from the task queue onto the available resources. The application may run in a limited environment with only one thread, but can also have many threads to execute work in parallel. Finally the work being executed can have side effects, which in turn can be its own change driver. This cycle will continue until the application state is stable.

Modeling​

The process automation component relies on information in the workflow model. It provides us with the following information:

  • DataElement: the target element in which workflow state is stored.
  • Workflow: separation between state-machines.
  • Transition: definition of all available state-transitions.
  • Trigger: change drivers associated with each transition.
  • WorkflowExecution: runtime configuration for each state machine.

More information on how to design a state-machine which correctly utilizes the process automation component can be found in the design guide. Configuration and performance tweaking of the workflow execution is covered in the configuration guide.

Application code​

The figure below depicts an overview of the expanded classes to give a better idea of how the resulting code will look and interact.

A few things to note:

  • Events are dispatched through the «DataElement»Events for each dataElement.
  • All change drivers are modeled using a Workflow Trigger.
    • «Workflow»EventHandler handles all defined onCreate, onModify and onTransition triggers.
    • «Transition»Schedule implements all schedule triggers for a specific transition.
    • «Workflow»EngineBean implements a subset of the FlowEngine trigger, to facilitate an easier migration path.
  • Each workflow has a «Workflow»Scheduler which can either dispatch a TaskJob to the queue or directly submit a job to be executed synchronously.
  • The QueuedProcessor WorkflowExecution consists of three parts, each present in the processAutomation component.
    • «Processor»QueuedProcessor contains the logic for interaction between the queue and the available processing resources. It will also perform a (dynamic) JNDI lookup to resolve a TaskJobExecutor, currently always a «Transiton»Transitioner.
    • «Processor»QueueDriver deals with the connection to the queue. By default, the component provides an ApplicationPersistence and InMemory queue driver.
    • «Processor»Processing is responsible for submitting TaskJobs to the underlying resources. The component provides Asynchrounous and ExecutorService implementations to use the JavaEE @Asynchronous and ManagedExecutorService APIs respectively.
  • Each transition has its own «Transition»Transitioner which deals with transactionality, task execution and recovery. It will also emit a «DataElement»TransitionEvent at the end of each transition.