7Tuning Siebel Workflow for Performance
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:
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 toTRUE
. In this case, Workflow Action Agent must be started manually. (It also must be started manually when you use email consolidation.)Use Action Agent
isFALSE
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
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.
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.
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
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.
Configuring Siebel CRM 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 the following table.
Table 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. |
Tuning Workflow Process Manager for Performance
This topic provides general approaches to tune and optimize performance of Workflow Process Manager.
You can follow the guidelines explained in the following information:
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.
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.
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 of ModelCacheMax
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.
See also Siebel System Administration Guide.