Skip to main content

Process Automation 1.7.0

· 3 min read
Jorren Hendriks
Jorren Hendriks
R&D Engineer

A brand-new release of the process-automation component is now available! There have been quite a few changes, mostly targeting stability, compatability and bug fixes. Some of the default configuration has changed, which may impact applications using a custom configuration. Read the migration guide below to verify if this applies to you!

Changes and improvements​

  • (Stability) {DataElement}Cruds will now return an error when trying to modify an element into an interim state outside a Task.
  • (Stability) Added error and recovery policies, allowing applications to configure how to deal with internal errors.
  • (Stability) Fixed some issues which would occur when transactions went into timeout.
  • (Compatability) Added support for applications using the ejb.interfaces.localOnly option.
  • (Compatability) Replace usage of TransactionManager with TransactionSynchronizationRegistry. This should be available in more JavaEE runtimes.
  • (Traceability) Added new monitoring anchors, to allow for more insight into applications running in production (more on this soon).
  • (Performance) ApplicationPersistent queue will now fetch the queue much sooner if the last fetch received the requested number of tasks.

Migration guide​

Moved files​

Some of the runtime classes have been moved to expanders or removed altogether. If you encounter any duplicate class or compiler errors, run a clean expand to make sure these files are removed.

Default execution​

The default execution has changed to incorporate the new policies model. The implemented policies have slightly different behavior to the previous default. When the error rate exceeds 30 errors per minute it will shut down the service. After 10 minutes of a service shutting down, recovery will be started. If these new defaults are not to your liking, you can of course define your own executions to override these settings.

default.xml (1.7.0+)
<workflowExecution type="processing::QueuedProcessor">
  <name>default</name>
  <maxConcurrentJobs>64</maxConcurrentJobs>
  <maxSubmittedJobs>15</maxSubmittedJobs>
  <queuePollingInterval>100</queuePollingInterval>
  <processing type="processing::Asynchronous"/>
  <queueDriver type="processing::ApplicationPersistence">
    <queueName>default</queueName>
    <pollingIntervalMs>5000</pollingIntervalMs>
    <localCacheCapacity>128</localCacheCapacity>
    <cleanupInterval>60</cleanupInterval>
  </queueDriver>
  <policies>
    <policy type="processing::ErrorRateShutdownPolicy">
      <whenErrorRateExceeds>30</whenErrorRateExceeds>
    </policy>
    <policy type="processing::ErrorRecoveryPolicy">
      <afterMinutes>10</afterMinutes>
    </policy>
  </policies>
</workflowExecution>
default.xml (1.6.x)
<workflowExecution type="processing::QueuedProcessor">
  <name>default</name>
  <maxConcurrentJobs>64</maxConcurrentJobs>
  <maxSubmittedJobs>15</maxSubmittedJobs>
  <queuePollingInterval>100</queuePollingInterval>
  <processing type="processing::Asynchronous"/>
  <queueDriver type="processing::ApplicationPersistence">
    <queueName>default</queueName>
    <pollingIntervalMs>5000</pollingIntervalMs>
    <localCacheCapacity>128</localCacheCapacity>
    <cleanupInterval>60</cleanupInterval>
  </queueDriver>








</workflowExecution>

Custom executions​

These policies also have to be applied to existing configurations. Otherwise, NO policy will be selected. Read more about configuring policies on the following page: "Managing Executions".

Polling interval​

Due to performance limitations some applications previously had to lower pollingIntervalMs on the ApplicationPersistence queue. With the improvements from this update this may no longer be needed. The recommendation is to revert this interval to 5000 (5s) and see if this meets your performance needs.

Modifies on interim states​

Due to changes in the Cruds, you will no longer be able to modify an element into an interim state unless the modification is performed within a workflow task. If your application relies on this behavior, for example in cases where the interim state is not unique (also used as begin/end state), you should reconfigure this workflow.