Step 6: Setting Up Background Workflow Engines

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 workflow process can also include a Wait activity, which defers the continuation of a process until a later time. This type of deferred activity is also completed by a background engine.

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:

The background engine sets the status of a stuck process to ERROR:#STUCK and executes the error process defined for it.

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

Background Engine Queues

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

See: Workflow Queue APIs.

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 scheduling the appropriate Workflow Background Process program to resubmit 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. However, for performance reasons Oracle recommends that you run three separate background engines at different intervals.

If you implement workflow RAC affinity, then you should also run background engines using the Workflow Background Process for RAC concurrent program. This program runs background engines that each process only the RAC-enabled workflows that were launched in a specific RAC instance. Running background engines with RAC affinity provides faster access to the workflow runtime data and helps avoid contention. See: Setting Up Workflow RAC Affinity.

You should run the Workflow Background Process for RAC program for deferred activities, timed out activities, and stuck processes as needed depending on the requirements of your RAC-enabled workflows. If the RAC-enabled workflows run on a particular schedule, then you should run the Workflow Background Process for RAC program on a corresponding schedule. You should also continue running the Workflow Background Process program to handle workflows that are not RAC-enabled. To ensure that RAC-enabled workflows are processed using RAC affinity, schedule the Workflow Background Process for RAC program to run before the Workflow Background Process program, particularly if you run the Workflow Background Process program without specifying an item type.

arrow icon   To Schedule Background Engines:

You submit the background engine procedure as a concurrent program, which lets you schedule different background engines to run at different times. Use the Submit Requests window in Oracle E-Business Suite to submit the Workflow Background Process or the Workflow Background Process for RAC. See: Overview of Concurrent Programs and Requests.

Additionally, you can use the Oracle Workflow Manager component of Oracle Applications Manager to submit and manage the Workflow Background Process concurrent program. See: Background Engines.

Note: You cannot submit the Workflow Background Process for RAC concurrent program through Oracle Workflow Manager. You must submit this program through the standard request submission UI.

Note: If you require a larger rollback segment for the Workflow Background Process than the default, you can use the Concurrent Programs window in the System Administrator responsibility to specify the rollback segment that you want. This rollback segment will be used instead of the default and will be used up until the first commit.

Query the Workflow Background Process concurrent program (FNDWFBG) in the Concurrent Programs window, and choose the Session Control button. Then in the Session Control window, enter the rollback segment you want in the Rollback Segment field, and save your work. See: Concurrent Programs Window.

To Run the Workflow Background Process as a Concurrent Program

  1. Navigate to the Submit Requests form.

  2. Submit the Workflow Background Process concurrent program (FNDWFBG) as a request. See: Running Reports and Programs.

  3. In the Parameters window, enter values for the following parameters:

    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 all item types.

    Note: If you implemented workflow RAC affinity, then the following conditions apply.

    • To obtain the performance benefits of workflow RAC affinity, you should run the Workflow Background Process for RAC program for the item types that include RAC-enabled workflow processes.

    • If any item types include both RAC-enabled and non-RAC workflow processes, then you should also run the normal Workflow Background Process program for those item types in order to handle the non-RAC workflow processes. Note that in this case the Workflow Background Process program executes eligible activities from all workflow processes in the specified item type, whether the processes are non-RAC or RAC-enabled, without respect to RAC affinity.

    • If you run the Workflow Background Process program without specifying an item type, then it executes eligible activities from all workflow processes in all item types, whether the processes are non-RAC or RAC-enabled, without respect to RAC affinity.

    • Consequently, to ensure that RAC-enabled workflows are processed using RAC affinity, schedule the Workflow Background Process for RAC program to run before the Workflow Background Process program, particularly if you run the Workflow Background Process program without specifying an 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 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 null 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.
    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.
    Process Stuck Specify whether this background engine checks for stuck processes. Setting this parameter to 'Yes' allows the engine to check for stuck processes.

    Note: Ensure that 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.

  4. Choose OK to close the Parameters window.

  5. When you finish modifying the run options to define the schedule for the background engine, choose Submit to submit the request.

To Run the Workflow Background Process for RAC as a Concurrent Program

  1. Navigate to the Submit Requests form.

  2. Submit the Workflow Background Process for RAC concurrent program (FNDWFBGRAC) as a request. See: Running Reports and Programs.

  3. In the Parameters window, enter values for the following parameters:

    Item Type Specify an item type to restrict this engine to activities associated with that item type. You can only select item types that include at least one RAC-enabled workflow process. See: To configure workflow processes for RAC affinity.
    To execute activities from RAC-enabled workflow processes in all item types, leave this parameter blank.

    Note: The Workflow Background Process for RAC program handles only RAC-enabled workflow processes. If any item types include both RAC-enabled and non-RAC workflow processes, then you should also run the normal Workflow Background Process program for those item types in order to handle the non-RAC workflow processes. Note that in this case the Workflow Background Process program executes eligible activities from all workflow processes in the specified item type, whether the processes are non-RAC or RAC-enabled. Consequently, to ensure that RAC-enabled workflows are processed using RAC affinity, schedule the Workflow Background Process for RAC program to run before the Workflow Background Process program, particularly if you run the Workflow Background Process program without specifying an 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 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 null 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.
    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.
    Process Stuck Specify whether this background engine checks for stuck processes. Setting this parameter to 'Yes' allows the engine to check for stuck processes.
    Partition Number Specify the partition number of the RAC instance associated with the workflow processes that this background engine executes. The background engine confines its processing to the workflows launched in that RAC instance, whose records are marked with that instance ID and stored in the partition for that instance within the workflow runtime tables. To execute RAC-enabled workflow processes in all partitions, leave this parameter blank.
    • If you specify both an item type and an partition number, then the Workflow Background Process for RAC program runs as a single concurrent request for that item type in that RAC instance partition.

    • If you specify an item type but leave the partition number blank, then the Workflow Background Process for RAC program submits separate concurrent requests to run a background engine for that item type in each RAC instance partition.

    • If you leave the item type blank but specify an partition number, then the Workflow Background Process for RAC program submits separate concurrent requests to run a background engine for each item type that includes a RAC-enabled workflow process in that RAC instance partition.

    • If you leave both the item type and the partition number blank, then the Workflow Background Process for RAC program submits separate concurrent requests to run a background engine for each item type that includes a RAC-enabled workflow process in each RAC instance partition.


    Because each of these background engine concurrent requests runs only in one partition within the workflow runtime tables, other background engines can access other partitions at the same time, providing faster access to the workflow runtime data.

    Note: Ensure that you have a least one background engine for RAC that can check for timed out activities, one that can process deferred activities, and one that can handle stuck processes.

  4. Choose OK to close the Parameters window.

  5. When you finish modifying the run options to define the schedule for the background engine, choose Submit to submit the request.

arrow icon   To Set Engine Thresholds:

To set the thresholds of background engines, specify the minimum threshold and maximum threshold arguments when starting the engine. The background engine then only processes activities with costs within your specifications.

The Workflow Engine threshold is set to 50 as a default. Activities with a cost higher than 50 are deferred for background engines to process.

In some cases, you may want to force the engine to defer an activity although the activity's cost is less than fifty. You can do this by altering the Workflow Engine threshold in the PL/SQL stored procedure for a function activity.

The engine threshold is set in an externalized constant called THRESHOLD. Include the following line in your PL/SQL procedure to set the Workflow Engine threshold to a different value:

WF_ENGINE.THRESHOLD := n; 

You should reset the threshold value afterwards in SQL*Plus or in the next function activity so that other activities are processed as expected.

Related Topics