Managing Executions

Out of the box the process-automation component provides the QueuedProcessor workflow execution type. By default, a processor which should work for most applications is provided. In some cases it can be needed to tweak the workflow configuration to suit your performance needs.

Queued Processor

As its name suggests, the queued processor handles two concerns; Queueing and Processing. Both can be configured and can even handle completely different implementations than provided by default.

Executions can be added as a dataResource in an expander bundle, or directly in the application through the settings directory. On this page we will provide examples for the settings directory, but it is trivial to apply this to a dataResource.

The default configuration looks as follows and is provided by the component. It is also possible to override this default, simply by defining a QueuedProcessor with the name default yourselves.

settings/queuedProcessor/default.xml

<workflowExecution type="processing::QueuedProcessor" name="default">
  <maxConcurrentJobs>64</maxConcurrentJobs>
  <maxSubmittedJobs>15</maxSubmittedJobs>
  <processing type="processing::Asynchronous"/>
  <queueDriver type="processing::ApplicationPersistence">
    <queueName>default</queueName>
    <pollingIntervalMs>5000</pollingIntervalMs>
    <localCacheCapacity>128</localCacheCapacity>
    <cleanupInterval>60</cleanupInterval>
  </queueDriver>
</workflowExecution>

Configuration	Description
maxConcurrentJobs	Maximum number of jobs taken from the queue at once.
maxSubmittedJobs	Maximum number of jobs submitted to the underlying processor at once.

An example of a custom workflow execution can be as follows. It is used for a polling workflow with an ExecutorService referenced by jndi, and using an in-memory queue. This queue is non persistent but since the execution is for polling it doesn't matter if some of the jobs are lost.

settings/queuedProcessor/polling.xml

<workflowExecution type="processing::QueuedProcessor" name="polling">
  <processing type="processing::ExecutorService">
      <jndiName>polling</jndiName>
  </processing>
  <queueDriver type="processing::InMemory"/>
</workflowExecution>

To use a non-default workflowExecution it needs to be added to the workflow configuration.

components/myComp/model/workflow/PollRecords.xml

<workflow name="PollRecords">
  ...
  <execution name="polling"/>
</workflow>

Work Schedules

Not all workflows should run continuously. A queued processor allows you to define a work schedule to indicate when the processor may be active. An example of such schedule is shown below:

settings/queuedProcessor/withSchedule.xml

<workflowExecution type="processing::QueuedProcessor" name="withSchedule">
  ...
  <workSchedules>
    <workSchedule>
      <startAt>06:00</startAt>
      <until>12:00</until>
    </workSchedule>
    <workSchedule>
      <startAt>15:00</startAt>
      <until>19:00</until>
      <timezone>Europe/Brussels</timezone> <!-- optional: specify timezone -->
    </workSchedule>
    <workSchedule>
      <startAt>00:00</startAt>
      <until>24:00</until> <!-- 24:00 results in 00:00 the next day -->
      <weekDay>sunday</weekDay> <!-- optional: specify day of week it is active -->
    </workSchedule>
  </workSchedules>
</workflowExecution>

The configuration above will result in a schedule as shown below, assuming the default timezone is UTC and Brussels is UTC+2.

Is there a need for more advanced schedules? See how to use calculated/runtime schedules in the advanced work schedule guide.

Processing Types

Processing is responsible for scheduling available tasks to an underlying resource. The implementation must always implement the net.democritus.processAutomation.TaskJobExecutorService interface. The component provides two types of processing by default; Asynchronous and ExecutorService.

• Asynchronous utilizes the javax.concurrent.Asynchronous api from JavaEE. It is supported by all application servers which adhere to the specification and should therefore always be available.

• ExecutorService makes use of an injected javax.enterprise.concurrent.ManagedExecutorService. Some applications such as TomEE provide a default, for others you may need to explicitly configure one.

  Configuration	Description
  jndiName	(optional) The jndi name of the resource, as configured on the application server.

Queue Types

Each type of queue needs a QueueDriver implementation. A ApplicationPersistence and InMemory driver are provided by default. It is of course possible to use different queueing technologies by implementing a driver as an expansionResource.

• ApplicationPersistence persists submitted jobs to a dataElement (TaskJobQueue) in the processAutomation component. The advantage is that these jobs will not be lost on a restart. The downside is a bit more overhead to maintain state for these jobs.

  Configuration	Description
  queueName	The name of the queue to use, can be shared over multiple queue drivers of this type
  pollingIntervalMs	Interval in milliseconds in which the database is polled for new tasks
  localCacheCapacity	The number of jobs to keep in memory, to avoid waiting on the next polling tick
  cleanupInterval	Number of seconds between runs of a cleanup removing all 'Committed' jobs (disabled at 0)

• InMemory is a non-persistent queue keeping all available jobs in memory. This provides a speed advantage with the downside of losing jobs when the application is restarted.