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.