Skip Headers
Oracle Workflow Administrator's Guide
Release 2.6.3.5
Part Number B12160-02
|
|
 |
 |
|
 |
 |
 |
| |
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.
- Synchronous--A synchronous process contains only activities that can be executed immediately, so that the Workflow Engine executes the process without interruption from start to finish. The Workflow Engine does not return control to the calling application until it completes the process. With a synchronous process, you can immediately check for process results that were written to item attributes or directly to the database. However, the user must wait for the process to complete. If the process takes a long time, the application may appear to hang. In this case, you should change the process to an asynchronous process.
- Asynchronous--An asynchronous process is a process that the Workflow Engine cannot complete immediately because it contains activities that interrupt the flow. Examples of activities that force an asynchronous process include deferred activities, notifications with responses, blocking activities, and wait activities. Rather than waiting indefinitely when it encounters one of these activities, the Workflow Engine sets the audit tables appropriately and returns control to the calling application. The workflow process is left in an unfinished state until it is started again, usually by the Notification System, Business Event System, or the background engine. With an asynchronous process, the user does not have to wait for the process to complete to continue using the application. However, the results of the process are not available until the process is completed at a later time.
- Forced synchronous--A forced synchronous process completes in a single SQL session from start to finish and never inserts into or updates any database tables. As a result, the execution speed of a forced synchronous process is significantly faster than a typical synchronous process. The process results are available immediately upon completion. However, no audit trail is recorded. You may want to use a forced synchronous process if your application needs to generate a specific result quickly and recording an audit trail is not a concern. To create a forced synchronous process, you must set the item key of your process to #SYNCH and follow certain restrictions in designing your process, such as not including any notification activities.
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:
- Storing working information for the work item.
- Token replacement for messages. For messages where the number of lines may vary, such as in repeating groups, do not create individual item attributes for each line. Instead, use item and message attributes of type Document to combine the lines together.
- Storing primary key values so that functions can look up all necessary values from the database.
- Temporary placeholders to set activity attributes dynamically. For example, the performer of a notification may only be known at runtime, so you can reference an item attribute and seed the desired value just before executing the notification.
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:
- Document--The attribute value is an embedded or attached document, which enables a complex structure to be rendered inline, or attached to notifications. You can specify the following types of documents:
- PL/SQL document--A document representing data from the database as a character string, generated from a PL/SQL procedure.
- PL/SQL CLOB document--A document representing data from the database as a character large object (CLOB), generated from a PL/SQL procedure.
- PL/SQL BLOB document--A document representing data from the database as a binary large object (BLOB), generated from a PL/SQL procedure.
- Oracle Applications Framework region - In Oracle Applications, a JSP call to an Oracle Applications Framework region for inclusion in a notification message.
- Role--The attribute value is the internal name of a role. If a message attribute of type role is included in a notification message, the attribute automatically resolves to the role's display name, eliminating the need for you to maintain separate attributes for the role's internal and display names. Also, when you view the notification from a web browser, the role display name is a hypertext link to the e-mail address for that role.
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.
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.
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
Copyright © 2003, 2004, Oracle. All rights reserved.