Tuning Workflow Processes

In order to improve performance when running workflow processes, you can follow the guidelines explained in the following topics:

• "Minimizing Usage of Parameter Search Specification"

• "Monitoring Conditions Based on Parent and Child Business Components"

• "Configuring Siebel Business Applications for Workflow Performance"

• "Monitoring Memory Overhead for Workflow Processes"

  
  

  Note: This performance tuning information is provided as general guidelines for tuning and optimizing performance of workflow processes. Every implementation of Siebel Business Applications is unique, so every use of workflow processes is also unique.

  
  

Minimizing Usage of Parameter Search Specification

This topic is part of "Tuning Workflow Processes".

Although the server component parameter Search Specification (alias SearchSpec) is a feature of Siebel Workflow, it is recommended that you minimize your use of this parameter with workflow processes that are frequently invoked.

Minimizing SearchSpec use, especially for frequently invoked processes, improves Workflow engine performance during runtime because the engine does not have to construct the SearchSpec string.

It is important, however, that you do not completely avoid using SearchSpec. Not using this parameter can indicate actions taking place on the current row in some cases, and on all rows in other cases. For specific guidelines, note the following:

• For Siebel operations, minimize usage of SearchSpec.

• For batch process requests, use SearchSpec on the business object to limit the number of rows processed.

Indexing Fields in SearchSpec

If you determine that SearchSpec does need to be used, then make sure that all of the fields being used are properly indexed. Proper indexing of the fields helps Siebel Workflow and the underlying database to efficiently build queries.

Monitoring Conditions Based on Parent and Child Business Components

This topic is part of "Tuning Workflow Processes".

When a condition is being evaluated at a decision step or any other step using a combination of parent and child business components, it is recommended that you closely benchmark the expression or the condition. In some cases, this will require spooling the SQL. For more information, see "Analyzing Generated SQL for Performance Issues".

Note: The query plan of the SQL might show an extended and poorly performing query. In such cases, it is better to break the conditions up into multiple decision steps and evaluate the conditions separately.

Configuring Siebel Business Applications for Workflow Performance

This topic is part of "Tuning Workflow Processes".

In some cases, you might need to perform a comparison between different objects.

Assume, for example, that a service request is assigned to a candidate depending on the industry of the account associated with it. In this case, it is necessary to perform a query against Account to fetch the appropriate industries, or to check an industry against all of the industries with which the account is associated.

If the workflow process in this example is going to be evaluated frequently, consider exposing Account Industry on Service Request by the appropriate configuration in order to enhance workflow performance.

Monitoring Memory Overhead for Workflow Processes

This topic is part of "Tuning Workflow Processes".

Overhead and performance and scalability characteristics vary depending on whether you are running workflows locally in the Siebel Application Object Manager or in Workflow Process Manager (WfProcMgr), and also on where you run WfProcMgr. The performance and scalability characteristics also depend on whether you are using asynchronous mode for workflow process requests. For more information, see Siebel Deployment Planning Guide and Siebel Business Process Framework: Workflow Guide.

Running Workflows Locally in Siebel Application Object Manager

A workflow instance (that is, one run of a workflow definition) can run within a Siebel Application Object Manager. In this case, the workflow runs locally, within the current thread that the logged-in user is using. This means that if N users are connected and they all need to run a workflow definition, then the definition would run in that user thread.

In this mode, Workflow adds a fixed overhead (100 to 200 KB) to the user session memory (sometimes referred to as the model) plus memory taken up by other objects (such as business components) contained in the tasks within that workflow.

In general, this option provides the best performance, but is suitable only where scalability is not an important factor.

Running Workflows in Workflow Process Manager

The workflow itself runs within a separate component, which uses a fixed set of resources (parameters MaxMTServers, MaxTasks) to schedule the workflow. The Workflow Process Manager component (alias WfProcMgr) is a multithreaded process that runs multiple workflows and is more scalable because it uses a pool of threads and models.

Generally, the mode of the workflow used depends on what the application is trying to achieve. It is generally recommended that you try to schedule a workflow task in WfProcMgr, especially if the results of a run are not immediately needed.

You can optionally run WfProcMgr on the same Siebel Server (colocating) as the Siebel Application Object Manager where the workflow is invoked, or run it on dedicated Siebel Server computers. Compared to running workflows locally, running workflows in WfProcMgr might reduce performance, but improve scalability. Running WfProcMgr on dedicated Siebel Servers typically provides the best scalability, while colocating WfProcMgr and Siebel Application Object Manager might provide better performance.

About Asynchronous Mode for Workflow Process Requests

For all Workflow Processes deployment options described previously, workflow process requests can be handled synchronously or using asynchronous mode. Using asynchronous mode comes with the advantages and disadvantages listed in Table 7-1.

Table 7-1 Advantages and Disadvantages of Using Asynchronous Mode

Advantages	Disadvantages
All user threads are not loaded. More scalable as long as: - There are maximum N simultaneously connected users. - There are maximum X simultaneous running workflows. - If X is smaller than N, then a WfProcMgr with X tasks can handle a much larger pool (N) of users.	On error, you must look at the log files, because there is no automatic notification. The SRBroker component could have a timeout or retry feature. Slightly more latency. Additional cost (minimal) of one request per response.