Previous	Next		Contents	Index	Glossary

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, and 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.

Additionally, a background engine must be set up to handle stuck processes. A process is identified as stuck when it has a status of ACTIVE, but cannot progress any further. For example, a process could become stuck in the following situations:

• A thread within a process leads to an activity that is not defined as an End activity but has no other activity modeled after it, and no other activity is active.

• A process with only one thread loops back, but the pivot activity of the loop has the On Revisit property set to Ignore.

• An activity returns a result for which no eligible transition exists. For instance, if the function for a function activity returns an unexpected result value, and no default transition is modeled after that activity, the process cannot continue.

The following table lists the standard queues used in background engine processing.

Queue Table	Queue Name	Payload Type	Retention Time	Description
WF_DEFERRED_QUEUE_M	WF_DEFERRED_QUEUE_M	SYSTEM. WF_PAYLOAD_T	0 days	Standard background deferred queue
WF_OUTBOUND_QUEUE	WF_OUTBOUND_QUEUE	SYSTEM. WF_PAYLOAD_T	0 days	Standard background outbound queue
WF_INBOUND_QUEUE	WF_INBOUND_QUEUE	SYSTEM. WF_PAYLOAD_T	0 days	Standard background inbound queue

Note: These queues are also used by the Java Function Activity Agent. See: Setting Up the Java Function Activity Agent and Workflow Queue APIs, Oracle Workflow API Reference.

You can define and start up as many background engines as you like to check for deferred and timed out activities.

Background engines can be restricted to handle activities associated with specific item types, and within specific cost ranges. A background engine runs until it completes all eligible activities at the time it was initiated.

Generally, you should set the background engine up to run periodically by either using a script or database job to restart the background engine periodically (for the standalone version of Oracle Workflow), or scheduling the Background Process concurrent program to resubmit periodically (for the version of Oracle Workflow embedded in Oracle Applications).

Ensure that you have at least one background engine that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes. At a minimum, you need to set up one background engine that can handle both timed out and deferred activities as well as stuck processes. However, for performance reasons we recommend that you run three separate background engines at different intervals.

• Run a background engine to handle only deferred activities every 5 to 60 minutes.

• Run a background engine to handle only timed out activities every 1 to 24 hours as needed.

• Run a background engine to handle only stuck processes once a week to once a month, when the load on the system is low.

See: To Start a Background Engine

See: To Schedule Background Engines

See: To Set Engine Thresholds

See: Activity Cost, Oracle Workflow Developer's Guide

See: Timeout Transitions, Oracle Workflow Developer's Guide

See: Deferring Activities

See: Wait Activity, Oracle Workflow Developer's Guide