This is an Activiti extension that implements timer retries. Alfresco Process Services includes the Activiti engine, so this can be considered an extension to that as well. The only requirement is that the package 'com.inteligr8.activiti.timer' is scanned by Spring. This is configured automatically for APS.

Install

You can install this like any JAR extension. It just needs to be put in the web container classpath.

Configuration

There is nothing to configure when used in APS. Outside of APS, you will need Spring to scan the com.inteligr8.activiti.timer package. Below is a pseudocode example:

@Configuration
@ComponentScan(basePackages = {
	...,
	"com.inteligr8.activiti.timer"
})
public class MyApplicationConfiguration {
}

Functionality

Activiti process models support timer start activities, intermediary timers, and timer boundary event listeners. The sections below describe how they act OOTB and how that changes with this extension.

For all timers, there are 3 different configurations that could be used.

Date: Timer fires at a fixed date/time. A variable may be used.
Duration: Timer fires after a fixed period of time. A variable may be used.
Cycle: Timer fires routinely, waiting for a fixed period of time between triggers.

Start Timer

A timer start model element is used to start a process at a specific time or constant repeating period. A finite retry could be useful here, but only in very rare circumstances. This is considered out-of-scope of this extension and any functionality around it remains how it is OOTB. To my knowledge, the start timer supports all timer definitions. A cycle definition is most useful and should work as expected. For instance, a cycle definition of R/PT30S will run the process every 30 seconds, repeating forever.

Intermediary Timer

An intermediary timer model element is typically used to sleep/wait for a period of time in the middle of a process. Because of the pause, it serves as a transaction boundary too. That means the current execution commits and after the timer expires, a new transaction commences.

OOTB, this timer supports date/duration definitions; duration definitions being very popular. A cycle definition may make sense, but it will not work as expected. It will act as a duration definition, no matter how you define the repeating nature. This is where this extension comes into play. With this extension, the attempts are tracked in a process instance variable and when the repeat count is reached, the timer will deadletter.

Boundary Timer

A boundary timer model element is typically used to expire a task that has taken too long. In the cases where you may be monitoring the completion of an asynchronous behavior, you may repeatedly check a status. In these cases, the timer may expire and loop back to the same task. And it will do this until the condition is met. Using a duration definition will make this loop indefinitely. Using a cycle definition will act just like a duration definition, even if you set a repeat limit.

This is where this extension comes into play. With this extension, the attempts are tracked in a process instance variable and when the repeat count is reached, the timer will stop firing; leaving the task in its current state.