Background engine processes serve three purposes in Oracle Workflow: to handle activities deferred by the Workflow Engine, to handle timed out notification activities, and to handle stuck processes.
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, 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 background engine sets the status of a stuck process to ERROR:#STUCK and executes the error process defined for it.
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.
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. Generally, you should run a separate background engine to check for stuck processes at less frequent intervals than the background engine that you run for deferred activities, normally not more often than once a day. Run the background engine to check for stuck processes when the load on the system is low.
You run a background engine by submitting the Workflow Background Process concurrent program (FNDWFBG). When you start a new background engine, you can restrict the engine to handle activities associated with specific item types, and within specific cost ranges. You can submit the Workflow Background Process concurrent program several times to schedule different background engines to run at different times.
To submit a request for the Workflow Background Process concurrent program through Oracle Self-Service Web Applications, choose Background Engine from the Submit Request For pull-down menu in the Workflow System Status page and click the Go button.
To view Workflow Background Process concurrent requests, either click the Background Engine link in the Process column in the Workflow System Status page, or select the Background Engine process and click the View Details button.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go
When you submit the Workflow Background Process concurrent program, specify the following parameters.
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 activity regardless of its item type.
Specify the minimum cost that an activity must have for this background engine to execute it, in hundredths of a second.
Specify the maximum cost that 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.
Specify whether this background engine checks for deferred activities. Setting this parameter to Yes allows the engine to check for deferred activities.
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.
Specify whether this background engine checks for stuck processes. Setting this parameter to Yes allows the engine to check for stuck processes.
Note: Make sure you have a 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.
When you view the Workflow Background Process concurrent requests, the Search Results page shows standard request detail information for these requests. For each request, the list displays the request ID, program short name, description, application short name, phase, status, requester, duration, and wait time. Click a column heading to sort the list by that column.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Background Engine
To show the details for a request if they are hidden, click the Show link in the Details column. Oracle Applications Manager displays details about the request depending on the status of the request. You can also perform actions, such as placing a hold on a request, canceling a request, viewing diagnostic information, viewing manager details, viewing logs, or viewing request output, by clicking the corresponding button. The actions that are available depend on the status of the request.
To hide the details for a request if they are shown, click the Hide link in the Details column.
To search for concurrent requests with different criteria, click the New Search button.
To modify the search criteria from this search, click the Modify Search button.