7 Tuning Siebel Workflow for Performance

This chapter provides guidelines for tuning workflow processes and policies to achieve and maintain optimal performance and scalability. It contains the following topics:

• "About Siebel Workflow"

• "Monitoring Workflow Policies"

• "Tuning Workflow Policies for Performance"

• "Tuning Workflow Processes"

• "Tuning Workflow Process Manager for Performance"

For more information about Siebel Workflow, see the following documents on the Siebel Bookshelf:

• Siebel Business Process Framework: Workflow Guide

• Configuring Siebel Business Applications

• Siebel System Administration Guide

About Siebel Workflow

Siebel Workflow is an interactive software tool that automates business processes.

Workflow processes are designed and administered using the Business Process Designer, a graphical user interface provided through Siebel Tools. Designing, planning, creating, and testing individual workflow processes using the Business Process Designer are described in detail in Siebel Business Process Framework: Workflow Guide.

Workflow Processes and Workflow Policies are two components of Siebel Workflow that are designed and created when automating a business process. These components are defined as follows:

• Workflow Processes. The representation of a business process. A workflow process comprises one or more steps that indicate when a business process starts and ends and includes information about individual activities within the business process.

• Workflow Policies. A systematic expression of a business rule. A workflow policy contains one or more policy conditions and one or more policy actions. If all of the policy conditions for a workflow policy are true, then the policy action occurs when all of the policy conditions are met. A workflow policy is contained by one workflow policy group and is related to one workflow policy object. A workflow policy contains additional properties that govern its behavior.

Monitoring Workflow Policies

You need to monitor Workflow Policies regularly to check that all events are handled correctly and that the Siebel Server uses its resources optimally. Purging your log files periodically prevents them from becoming too large. Workflow Policies use the General Events event for logging. To see informational messages, set the log level to 3. To see debugging information, set the log level to 4.

You can monitor Workflow Policies using the following views, log files, and tables:

• Policy Frequency Analysis view. For details, see "Using the Policy Frequency Analysis View".

• Workflow Agent trace files. For details, see "Using Workflow Agent Trace Files".

• Workflow Policies tables. For details, see "Monitoring Workflow Policies Tables".

Using the Policy Frequency Analysis View

This topic is part of "Monitoring Workflow Policies".

The Policy Frequency Analysis view provides a list of all executed policies. The Policy Frequency Analysis view is available to analyze how frequently policies are executed over time.

This view displays a log of all of the policies executed, as evidenced by a Workflow Monitor Agent process. The policy maker can monitor Workflow Agent process activity to determine whether the current policies are adequate, new policies need to be created, or policies need to be refined.

The Policy Frequency Analysis view lets you view Policy Log data in a graphical format. The log information is generated by Siebel Server components for Workflow Policies. You access the Policy Frequency Analysis view from the Siebel client by navigating to Policy Frequency Analysis view in the Administration - Business Process screen.

The Policy Frequency Analysis view contains the following fields:

• Policy. The name of the policy that was executed.

• Workflow Object. The name of the assigned workflow policy object.

• Object Identifier. The ID of the workflow policy object for which the policy was executed.

• Object Values. Identifying information for the row that executed the policy.

• Event. The date and time of the policy execution event.

Using Workflow Agent Trace Files

This topic is part of "Monitoring Workflow Policies".

Workflow agent trace files include the following:

• Workflow Monitor Agent trace file. Workflow Monitor Agent provides detailed information about its processing in its trace file.

• Workflow Action Agent trace file. Workflow Action Agent provides detailed information about its processing in its trace file.

  Setting tracing on the Workflow Action Agent task is required only when the parameter Use Action Agent for Workflow Monitor Agent is set to TRUE. In this case, Workflow Action Agent must be started manually. (It also must be started manually when you use email consolidation.)

  Use Action Agent is FALSE by default: Workflow Action Agent is started automatically by Workflow Monitor Agent.

• Email Manager and Page Manager trace files.

  • Run Email Manager and Page Manager components with Trace Flag set to 1 for detailed reporting on email activity.

  • Query S_APSRVR_REQ for status information on email and page requests that were logged by Workflow Action Agent.

Monitoring Workflow Policies Tables

This topic is part of "Monitoring Workflow Policies".

Workflow Policies use three database tables for processing and tracking requests:

• S_ESCL_REQ

• S_ESCL_STATE

• S_ESCL_ACTN_REQ

Monitor these tables to verify that policies are being processed correctly.

When a trigger fires against a Workflow Policy condition, a record is inserted in the escalation request table, S_ESCL_REQ. Records in this table identify rows in the database that could trigger a Workflow Policy to take action. After the workflow Monitor Agent processes a request, it removes the row from this table.

The S_ESCL_STATE time-based table identifies all of the rows that have been executed (all conditions are true) and are waiting for the time duration element to expire.

The S_ESCL_ACTN_REQ table identifies all of the rows that are awaiting action execution. These rows have violated the policy; and the time duration element, if any, has expired.

If one of these tables (S_ESCL_REQ, S_ESCL_STATE, and S_ESCL_ACTN_REQ) becomes very large, then this could indicate that the number of policies being monitored is too large, and new Workflow Policies processes need to be created to share the load and improve performance.

If rows are being monitored, but are not being removed from a table after the time interval is met, then this could indicate that a policy was deactivated without removing the database triggers. The triggers are continuing to send data that is not being acted on by a Workflow Policies process. These tables will become very large if you do not restart Generate Triggers.

If you expire or delete any active Workflow Policies, confirm that no outstanding records remain in the S_ESCL_REQ, S_ESCL_STATE, or S_ESCL_ACTN_REQ tables.

Maintain the S_ESCL_REQ, S_ESCL_STATE, and S_ESCL_ACTN_REQ tables by adjusting parameters related to storage, access, and caching. See database documentation for additional information about properly adjusting such parameters. Also, make sure that the database administrator (DBA) is aware of these key tables.

Tuning Workflow Policies for Performance

Workflow Policies can be tuned to optimize your resources while also meeting the policy's timing requirements by grouping similar policies and assigning these policy groups to Siebel Servers that can handle the workload. Performance tuning can be handled in several interrelated ways. The following topics provide more information:

• "Creating Workflow Policy Groups to Manage Siebel Server Load"

• "Multiple Workflow Monitor Agents and Workflow Action Agents"

• "Running Workflow Agents on Multiple Siebel Servers"

• "Setting Optimal Sleep Interval for Workflow Policy Groups"

• "Setting Optimal Action Interval for Workflow Monitor Agent and Workflow Action Agent"

Creating Workflow Policy Groups to Manage Siebel Server Load

This topic is part of "Tuning Workflow Policies for Performance".

Workflow policy groups allow you to group policies with similar polling intervals. This distributes the load to allow efficient processing. For example, if you have very critical policies that must be responded to within minutes of the policy trigger event and you have other policies that need a response within a day, then you can assign them to different workflow policy groups.

The advantage of selective grouping is that a Workflow Agent's polling resources are focused on a smaller number of policies, which helps make monitoring and action execution more effective.

Multiple Workflow Monitor Agents and Workflow Action Agents

This topic is part of "Tuning Workflow Policies for Performance".

Each Workflow Agent combination monitors the policies within its assigned workflow policy group. If you are a high-volume call center or you have a large number of policies that need very short polling intervals, then you might want to create multiple groups with Workflow Agent processes to run in parallel. A single Workflow Agent process that is monitoring and handling a large number of events can become slow to respond and not meet the time interval commitments set by the policy.

Running multiple Workflow Monitor Agent and Workflow Action Agents in parallel:

• Focuses a component's polling resources on a smaller number of workflow policies.

• Allows faster throughput by shortening the time between when the workflow policy event is triggered and when the component notices the event.

Running Workflow Agents on Multiple Siebel Servers

This topic is part of "Tuning Workflow Policies for Performance".

You can run Workflow Agent processes on different Siebel Servers to ease the workload on each Siebel Server. You can then adjust the polling interval for each group so that polling for noncritical policies does not prevent efficient processing of critical policies.

By distributing workflow policy processes across Siebel Servers:

• High-maintenance policies can be grouped on a Siebel Server with sufficient resources to handle the workflow CPU requirements.

• Low-maintenance policies can be run on a Siebel Server that shares resources with other Siebel processes.

Setting Optimal Sleep Interval for Workflow Policy Groups

This topic is part of "Tuning Workflow Policies for Performance".

By creating groups with similar polling intervals, you can assign the workflow policy group to a Workflow Agent process with a polling rate that matches the workflow policy group. Different polling intervals can be assigned to each workflow policy group using the Sleep Time parameter. For more information about Workflow Policies server administration, see Siebel Business Process Framework: Workflow Guide.

After Workflow Agents process all requests, the agent processes sleep for the interval specified by this argument before processing begins again. Set the sleep intervals as large as is possible, but at an interval that still meets your business requirements.

Note: Setting sleep intervals at values that are too small can put undue stress on the entire infrastructure. Make sure that the sleep interval is as large as possible within the context of the business process.

Adjust the sleep interval for each Workflow Agent process to meet the requirements of each workflow policy group.

For example, workflow policy group A contains accounts that require a response to a Severity 1 service request within 10 minutes. Workflow policy group B contains policies that require a customer follow-up call within 14 days.

Workflow policy group A is very time-critical, so you could set the sleep interval to 60 seconds so that the assigned Workflow Policies instance polls frequently. Workflow policy group B is not as time-critical, so you could set the sleep interval to 48 hours and the Workflow Policy instance can still meet its commitments.

Another example where optimal configuration of the Sleep Time parameter might be required is in the case of multiple users who might need to update the same record. If you have, for example, a workflow policy that monitors service requests and you have multiple users that retrieve and modify open service request records, then you need to set the sleep time parameter so that users will have enough time to update the text fields.

If the sleep interval is not set high enough, then you might encounter an error message stating: The selected record has been modified by another user since it was retrieved. Please continue. In this case, you will lose your changes as the new field values for this record are displayed.

Note: If you find that Workflow Policies runs significantly slower during a certain time period, then investigate what other processes might be contending for CPU resources on the Siebel Server. You might discover that the Siebel Server has certain time periods with high activity that interfere with the ability of the Workflow Policies process to monitor or act. Arrange the Workflow Policies processes on the Siebel Servers so that the polling periods are compatible with the resources available.

Setting Optimal Action Interval for Workflow Monitor Agent and Workflow Action Agent

This topic is part of "Tuning Workflow Policies for Performance".

For each Workflow Monitor Agent or Workflow Action Agent component, you can set the Action Interval parameter, which determines when actions for a given policy are re-executed on a given base table row. This setting limits the number of times actions are executed if a row keeps going in and out of a matching condition.

You set the Action Interval parameter for Workflow Monitor Agent (rather than Workflow Action Agent) if you have set the parameter Use Action Agent to TRUE for Workflow Monitor Agent. Use Action Agent is FALSE by default.

For example, if a service request severity is set to critical and triggers a policy, then you do not want to re-execute the policy action if it is changed and has been reset to critical during this interval.

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, 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 the 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 could have a timeout or retry feature. Slightly more latency. Additional cost (minimal) of one request per response.

Tuning Workflow Process Manager for Performance

This topic provides general approaches to tune and optimize performance of Workflow Process Manager.

Note: Every implementation of Siebel applications is unique, and so every use of workflow processes is also unique. It is in your best interest to test, continually monitor, and tune your workflow processes to achieve optimal throughput.

You can follow the guidelines explained in the following information:

• "Caching Business Services"

• "Caching Sessions"

• 
  

  Note: Consider the information provided in this topic as general background information. No attempt is made to detail the many variables that affect tuning at specific sites. This content is not a substitute for specific tuning recommendations made by Global Customer Support or other Oracle service organizations.

  
  

Caching Business Services

This topic is part of "Tuning Workflow Process Manager for Performance".

Business services invoked through Workflow Process Manager must have the Cache property set to TRUE. This feature makes it possible for the Workflow engine to not reload and reparse the business service, and therefore enhances the performance of workflows that invoke business services.

Note: Predefined Siebel business services that have the Cache property set to FALSE must not be reset to TRUE.

Caching Sessions

This topic is part of "Tuning Workflow Process Manager for Performance".

The parameter OM - Model Cache Maximum (alias ModelCacheMax) for Workflow Process Manager determines the size of the cache for model objects (also known as cached sessions). Cached sessions maintain database connections and session data for locale, user preferences, and access control.

Note: Session caching applies only to noninteractive Object Manager-based server components like Workflow Process Manager. It does not apply to Siebel Application Object Manager or EAI Object Manager components.

This feature maintains and reuses existing sessions rather than creating a new session each time one is requested. Using this feature can improve login performance for Workflow Process Manager.

Each model in the cache creates two database connections for the life of the model: one connection for insert, update, and delete operations; another connection for read-only operations.

The default value is 10. A value of 0 disables this parameter. The maximum value is 100. In general, you set ModelCacheMax to a value approximately equal to the number of concurrent sessions the Workflow Process Manager component is expected to support.

Note: When component sessions use multiple user IDs, session caching provides less benefit relative to its cost. The benefit is greatest for component sessions using the same user ID.

See also Siebel System Administration Guide.