|
|
|
|
|
|
|
|
|
| Previous | Next | Contents | Index | Navigation | Glossary | Library |
When the Workflow Engine initiates and performs a process, it completes all necessary activities before continuing to the next eligible activity. In some cases, an activity can require a large amount of processing resource or time to complete. Oracle Workflow lets you manage the load on the Workflow Engine by setting up supplemental engines to run these costly activities as background tasks. In these cases, the costly activity is deferred by the Workflow Engine and run later by a background engine. The main Workflow Engine can then continue to the next available activity, which may occur on some other parallel branch of the process.
A background engine must also be set up to handle timed out notification activities. When the Workflow Engine comes across a notification activity that requires a response, it calls the Notification System to send the notification to the appropriate performer, then sets the notification activity to a status of 'NOTIFIED' until the performer completes the notification activity. Meanwhile, a background engine set up to handle timed out activities periodically checks for 'NOTIFIED' activities and whether these activities have time out values specified. If a 'NOTIFIED' activity does have a time out value, and the current date and time exceeds that time out value, the background engine marks that activity as timed out and calls the Workflow Engine. The Workflow Engine then resumes by trying to execute a <Timeout> transition activity.
You can define and start up as many background engines as you like to check for deferred and timed out activities. Background engines run for a specified period of time, and can be restricted to handle activities associated with specific item types, and within specific cost ranges.
To Run a Workflow Background Process:| Item Type | Specify an item type to restrict this engine to activities associated with that item type. If you do not specify an item type, the engine processes any deferred activity regardless of its item type. |
| Minimum Threshold | Specify the minimum cost that an activity must have for this background engine to execute it, in hundredths of a second. |
| Maximum Threshold | Specify the maximum cost an activity can have for this background engine to execute it, in hundredths of a second. |
| By using Minimum Threshold and Maximum Threshold you can create multiple background engines to handle very specific types of activities. The default values for these arguments are 0 and 100 so that the background engine runs activities regardless of cost. | |
| Process Deferred | Specify whether this background engine checks for deferred activities. Setting this parameter to 'Yes' allows the engine to check for deferred activities. Setting this parameter to 'No' restricts the engine to check only for timed out activities. |
| Process Timeout | Specify whether this background engine checks for activities that have timed out. Setting this parameter to 'Yes' allows the engine to check for timed out activities. Setting the value to 'No' restricts the engine to handling only deferred activities. |
Note: Make sure you have a least one background engine that can check for timed out activities and one that can process deferred activities. At a minimum, you need to set up one background engine that can handle both timed out and deferred activities.
| Previous | Next | Contents | Index | Navigation | Glossary | Library |