Skip Headers

Oracle Workflow Administrator's Guide
Release 2.6.3.5

Part Number B12160-02
Previous Next       Contents Index Glossary
         Previous  Next          Contents  Index  Glossary

Designing Workflow Processes for Performance

You can enhance the performance of your workflow processes through effective process design.

Synchronous, Asynchronous, and Forced Synchronous Workflows

When designing a workflow process, you must decide whether you want it to be executed as a synchronous, asynchronous, or forced synchronous process. The process design impacts the amount of time it takes for the Workflow Engine to return control to the calling application that initiates the process.

See Also

Overview of the Workflow Engine, Oracle Workflow API Reference

Synchronous, Asynchronous, and Forced Synchronous Processes, Oracle Workflow API Reference

Item Attributes

Item attributes act as global variables that can be referenced or updated by any activity within a workflow process. The number of item attributes directly affects the startup time for work items, because the Workflow Engine creates runtime copies of all item attributes when a new work item is created. For this reason, item attributes should be kept to a minimum.

Item attributes should be used for:

Item attributes should reference static values or values that are not in the database so that there are no concerns about keeping the values synchronized. (Primary key values, however, do not change.) Do not implement every column within a table as an item attribute.

Item attribute types that can help you reduce the number of attributes you need include the following:

Whenever multiple item attributes will be created, or multiple item attribute values will be set during workflow processing, use the array versions of the Add Item Attribute and Set Item Attribute workflow engine APIs (AddItemAttributeArray and SetItemAttributeArray, respectively). These APIs will significantly decrease the number of calls to Workflow Engine APIs, which can have a measurable impact on performance during batch processing. See: AddItemAttributeArray, Oracle Workflow API Reference and SetItemAttributeArray, Oracle Workflow API Reference.

See Also

Item Type Attributes, Oracle Workflow Developer's Guide

Attribute Types, Oracle Workflow Developer's Guide

To Define an Item Type or Activity Attribute, Oracle Workflow Developer's Guide

Message Attributes

To enhance performance, message attributes should be kept to a minimum. For messages where the number of lines may vary, such as in repeating groups, do not create individual item and message attributes for each line (LINE_INFO1, LINE_INFO2, etc.). Instead, use item and message attributes of type Document to combine the lines together.

See Also

Attribute Types, Oracle Workflow Developer's Guide

Send and Respond Message Attributes, Oracle Workflow Developer's Guide

To Define a Message Attribute, Oracle Workflow Developer's Guide

Subprocesses

When you design a workflow process, you can group a collection of activities together in a process activity which represents a subprocess within the main process. Using subprocesses judiciously can help make workflow diagrams clearer and easier to read and can simplify workflow monitoring and maintenance. However, subprocesses also result in additional DML operations and additional state information stored in Workflow tables. Consequently, you should avoid unnecessary use of subprocesses when there is no functional benefit.

For example, the following two processes, Process 1 and Process 2, are functionally identical, both performing a function called Function 1. However, they result in different numbers of state rows being stored in Workflow tables.

Process 1 contains a Start activity, a Subprocess activity, and an End activity. The subprocess contains a Start activity, the Function 1 activity, and an End activity. This process stores 7 state rows in Workflow tables.

image described in text

Process 2 simply contains a Start activity, the Function 1 activity, and an End activity. This process stores only 4 state rows in Workflow tables.

image described in text

Because more rows are stored in Workflow tables, the kind of design shown in the Process 1 diagram will result in slower workflow throughput and a need to purge Workflow runtime tables more frequently than what should be necessary with the Process 2 design.

Note: This guideline is not meant to imply that subprocesses should not be used at all. Collapsing all subprocesses can make workflow diagrams unreadable and difficult to maintain. This recommendation merely highlights that unnecessary overuse of subprocesses can have a negative performance impact.

See Also

Process Activity, Oracle Workflow Developer's Guide

To Create a Process Activity, Oracle Workflow Developer's Guide

Deferring Activities

The simplest and most effective way to improve the online user's response time is to defer function activities. You may want to defer activities that require a large amount of processing resource or time to complete. Oracle Workflow lets you manage the load on the Workflow Engine and the response time for the user 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.

When an activity is deferred, the main Workflow Engine can then continue to the next available activity, which may occur on some other parallel branch of the process. If no other activity is available to be executed, the Workflow Engine returns control immediately to the calling application. The user remains unaware that processing is still taking place, rendering a faster execution time.

To defer an activity, set the activity's cost above the default threshold cost at design time. The threshold cost is a PL/SQL package variable with a default value of 50 hundredths of a second. Set a cost above this threshold for all activities that you don't want the user to wait for.

At runtime, the Workflow Engine defers any thread to the background as soon as it encounters an activity with a cost higher than the threshold. Then the background engine later identifies the process as deferred and continues its execution.

In addition to deferred activities, background engines also handle timed out activitites and stuck processes. You can run as many background engines as you want. You must 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.

See Also

Deferred Processing, Oracle Workflow API Reference

Activity Cost, Oracle Workflow Developer's Guide

Setting Up Background Workflow Engines

To Set Engine Thresholds


         Previous  Next          Contents  Index  Glossary



Oracle Logo
Copyright © 2003, 2004, Oracle. All rights reserved.