General

Supported Timer Events

Timers are currently supported on the following event objects:

  • Start Event - Timer controls when the process starts.
  • Intermediate Catch Event - the timer delays the process flow and controls when the process moves on to the next event.
  • Timer Boundary Events - interrupting and non-interrupting timer boundary events can be set on tasks, userTask, and subProcess objects to implement reminder, timeout, and period closing processes. Non-interrupting timer boundary events can fire repetitively to create repeating reminders. 🆕
  • Event Based Gateway. Timers can be used following an Event Based Gateway. The Event Based Gateway choses which single path is taken, based on which Event occurs first.

When using timers, the properties viewer window is used to specify the timer type and details.

Initial setup of the Timer sub-system requires additional database privileges and configuration, so you might need to configure your timer sub-system and check that it is working correctly if you have not used timers before on your system. Timers use the Oracle DBMS_SCHEDULER mechanism, and initial Flows for APEX set-up requires privilege to create a Job and a Process. Operation of timers inside a business process does not require users to have these privileges.

From v22.1, timers can be specified in ISO 8601 format or in Oracle date and interval formats. Details of the syntax and substitutions allowed are shown here.🆕

Timer Start Event

The Timer Start Event allows a process start to be delayed so that it occurs at a particular date & time, after a delay, or on a regular scheduled basis.

Simple Timer Event Start

If you want to start a regular, repeating start event – for example, a process that runs every week to generate a sales report – you should use APEX automations to create a regular event, and have the Automation start a process instance by calling flow_api_pkg.create_process().

Timer Intermediate Catch Event

A Timer Intermediate Catch Event will cause the sequence flow to wait until the timer fires, thus causing a delay to the sequence flow.

Simple Timer Intermediate Catch Event

Interrupting Timer Boundary Event

These can be set on a task, a userTask, a manualTask, or a subProcess. When this object becomes the current task, a timer is started. If the object is still the current object when the timer fires because it has not yet been completed, the underlying task is terminated, and the timer boundary event becomes the current object. It performs a task_complete on the boundary event, moving the process on to the next step. These are used to perform a business process timeout – the usual forward path is suspended, and replaced by the timeout process path. This can also be used to move a process on after a period closes or a review period has completed. Only one interrupting timer can be set on each object. In the example below, task C has an attached interrupting timer. If task C is completed before the timer fires, the timer is removed. If the timer fires before C has completed, processing switches from the normal path and instead continues with C Timeout as the next task.

Timer Boundary Events

Non Interrupting Timer Boundary Events

These can be set on a task, a userTask, a manualTask, or a subProcess. When this object becomes the current task, a timer is started. If the object is still the current object when the timer fires because it has not yet been completed, the underlying task continues, and a new subflow starts to operate in parallel to execute the ‘reminder’ path. The new ‘reminder path’ performs a task_complete on the boundary event, moving the process on to the first task on that path. Non-Interrupting Timer Boundary Events are used to implement reminder processes, or to start time-delayed parallel process paths. If the underlying task completes before the timer fires, the ‘reminder path’ timer and associated subflow are deleted. Non-Interupting Timer Boundary Events can be configured to fire repetitively, either indefinitely or limited to a specified maximum number of repetitions / cycles. Multiple non-interrupting timer events can be set on a single task, userTask, manualTask, or subProcess. In the example above, task A has one non-interrupting boundary timer attached to it. If task A is not completed in the given 20 seconds, the timer fires - which starts task ‘A Reminder’ on a parallel subflow to the main subflow.

Event Based Gateways

An Event Based Gateway is used to control the forward path of a process depending upon which event occurs first. An Event Based Gateway is followed by one or more event-based Intermediate Catch Events (which can include a Receive Task, which looks like a catch event!). When the process flow gets to the Event Based Gateway, all of its following catch events become active, and wait for their respective event to occur. When the catch event occurs on one of the forward paths, the process proceeds along that path only. All other paths forward from the Event Based Gateway are terminated.

DIAGRAM

Event Based Gateway with Message Catch Event and Timer Event.

A common design pattern for an Event Based Gateway is a Message Catch Event with a Timeout. This is modelled using an Event Based Gateway, withtwo forward paths.

  • the first forward path contains the Message Catch Event, which is waiting for a specific formatted message to arrive into the system via messageFlow.
  • the second forward path is an Intermediate Timer Catch Event, which is congigured to fire after a timeout period, say 12 Hours.

More information about MessageFlow is contained here. LINK TO NEW PAGE ON MESSAGEFLOW

DIAGRAM

When the process sequenceFlow reached the Event Based Gateway, it starts two new subflows - one with the Message Catch event as its current step, and the other with the Timer as its current Event. The process is now waiting for either a message to arrive or the timer to fire. When the first of these expected events occurs, the path containing the caught event becomes THE forward path. Its subflow ID is switched to the subflow ID entering the Event Based Gateway. All other forward paths from the Event Based Gateway are terminated, and their catch events terminated and cleaned-up. And the process moves on to the next step after the “winning” catch event.

CHANGE DIAGRAM

Example Event Based Gateway sequence

Event Based Gateways or Boundary Events?

You might have noticed that the example above implemented a message catch with an associated timeout, and this was implemented using an Event Based Gateway, a Message Catch Event, and a Timer Catch Event. Message Catch and Throw Events have very similar operational behaviour to the Task-based messageFlow objects, ReceiveTask and SendTask. An equivalent way to provide the same functionality would be to model this message catch with associated timeout as a ReceiveTask and an attached Interrupting Timer Boundary Event. Both are possible with Flows for APEX. Modern BPMN style generally prefers the Event Based syntax over the Task Based syntax.

** DIAGRAM**

Setting Up the Timer System

See the dedicated section in the installation documentation.