Timer delays and event delays pause an operation until an order rule evaluates as true. Timer delays and event delays work identically, but the timing for the rule evaluation differs as follows:
The order rule on a timer delay is evaluated at specified time intervals. The frequency at which the OSM server evaluates the timer delay rule is determined by your OSM server configuration. See OSM Installation Guide for more information.
The order rule on an event delay is evaluated only when the data referenced in the rule changes.
Note:
Compensation ignores timer delays and event delays when undoing and redoing the tasks in a process.See "About the Process Editor Activities Drawer" for information about adding timer delays and event delays to a process.
By default, timer delays use the null_rule. To use OSM resources efficiently and minimize database table entries, Oracle recommends that you define a custom order rule and apply it to the timer delay. By applying an order rule to the timer delay, you avoid creating a separate automated task to evaluate the rule.
See "Defining Order Rules" and "Applying Order Rules to Timer Delays" for more information.
To apply an order rule to a timer delay:
In the Process editor, right-click the timer delay.
Select Show Properties.
The Properties view for the timer delay opens.
Select the Condition property and click inside the Value field.
Select a custom order rule for the timer delay.
Click Save.
Because event delays can only detect data changes that happen after the event delay starts, you must model your cartridges so that the event delay starts before the task or process that triggers the data change.
For example, imagine you have a cartridge project with two parallel processes. Process A includes an event delay that pauses until Process B updates some order data. If you model the project so that Process A reaches the event delay before Process B begins, when Process B updates the data, the event delay detects the data change, evaluates the order rule, and resumes Process A if the rule evaluates as true.
However, if you model the project so that Process B updates the data before Process A reaches the event delay, the event delay does not detect the data change, does not evaluate the order rule, and continues to delay Process A indefinitely.