|
Siebel Business Process Framework: Workflow Guide > Administering, Testing, and Migrating Workflow Policies > Administering Workflow Policies >
Running a Workflow Policy with Workflow Monitor Agent
This topic includes the following topics:
About the Workflow Monitor Agent
The Workflow Monitor Agent (WorkMon) is a server component that determines if the workflow policy conditions are met and runs actions. To run workflow policies, you must start the Workflow Monitor Agent. You can start and stop the Workflow Monitor Agent server task in the Administration-Server views. Tables That Workflow Monitor Agent Uses
Table 67 describes some of the Siebel database tables that Workflow Monitor Agent uses.
Table 67. Tables That Workflow Monitor Agent Uses
|
|
S_ESCL_REQ |
Escalation request. Contains the potential matching requests that an application causes. For more information, see Fixing Problems in the S_ESCL_REQ Table. |
S_ESCL_STATE |
Escalation state. Contains the policy matches that describe time. |
S_ESCL_ACTN_REQ |
Escalation action request. Contains the requests to run actions, which Siebel CRM uses only if Use Action Agent is TRUE. |
S_ESCL_LOG |
Escalation log. Contains a history of rows in the base table that contains matched policies. |
How the Workflow Monitor Agent Runs Workflow Policies
The Workflow Monitor Agent runs several server processes that monitor the Siebel database. It does the following:
- Examines the S_ESCL_REQ table to determine when the workflow policy conditions are met.
- Monitors workflow policies in a single group. You can run only one process of the Workflow Monitor Agent on one group at one time. If you run two processes on the same group, then a deadlock can occur. You can run multiple processes at the same time but you must run each process on a different group.
- If the Action Agent parameter is True, then Workflow Monitor Agent creates requests for the Workflow Action Agent in the S_ESCL_ACTN_REQ table.
- Purges requests from the S_ESCL_REQ table after processing finishes. If Siebel CRM activates a database trigger because a workflow policy condition is met, then it inserts a record in the S_ESCL_REQ table. The Workflow Monitor Agent evaluates the request on the rules that the policies in the workflow policy group establish.
The Workflow Monitor Agent handles a request in one of the following ways:
- Action Agent is True and the request in the S_ESCL_REQ table does not include a duration in the workflow policy. The Workflow Monitor Agent logs an entry in the S_ESCL_LOG table and sends the request to the S_ESCL_ACTN_REQ table.
- Action Agent is True and the request in the S_ESCL_REQ table does not include a duration in the workflow policy. The request remains in the S_ESCL_STATE table until the duration is met or until Siebel CRM removes the request because the workflow policy conditions are no longer met. Workflow Monitor Agent evaluates each request that remains in the S_ESCL_STATE table for a duration or to determine if the condition still matches values in the S_ESCL_STATE table. As each match occurs, Workflow Monitor Agent logs an entry in the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table.
How Workflow Monitor Agent Calculates the Duration
If a workflow policy includes a duration, then Siebel CRM calculates the duration starting with the time that the Workflow Monitor Agent detects that the row is in violation of the policy. It does not start the duration from when Siebel CRM inserts the row in the S_ESCL_REQ table. For example, assume you define a workflow policy and set the duration as one week, but you do not start the Workflow Monitor Agent until several days after Generate Triggers runs. In this example, the workflow policy action runs one week from when Workflow Monitor Agent starts. It does not run one week from when you create the workflow policy or when Generate Triggers runs. Managing the REQ_ID Column of the S_ESCL_REQ Table
The REQ_ID column of the S_ESCL_REQ table (S_ESCL_REQ.REQ_ID) can hold up to 9 digits. Siebel CRM allows a maximum value of 999,999,999. The sequence in the S_ESCL_REQ_S table does not contain an upper boundary, so the sequence for S_ESCL_REQ.REQ_ID can potentially create a number that is greater than the 9 digit maximum. This situation might cause an overflow. To avoid this situation, it is recommended that you do one of the following:
- Use a database tool to increase the column size
- Use a database tool to reset the S_ESCL_REQ_S sequence
As a separate problem, you might encounter a message that is similar to the following: Status: Deleting requests a numeric identifier.
This message does not indicate the number of rows that Workflow Monitor Agent is deleting. The numeric identifier indicates the REQ_ID from the S_ESCL_REQ table, which Siebel CRM creates to uniquely identify the rows in the Siebel database. Siebel CRM create the value for the REQ_ID in the following ways:
- From the Sequence object in an Oracle database
- From the identity column in an MS SQL Server database
- From the User Defined Function (UDF) in a DB2 database
There is no correlation between REQ_ID and the number of rows in the S_ESCL_REQ table. Using Replication with the Workflow Monitor Agent
Only one Workflow Monitor Agent and Workflow Action Agent can monitor a workflow group in a Siebel Enterprise. For example, assume a regional node runs a Workflow Monitor Agent that monitors a group named Group 1. Another Workflow Monitor Agent that resides in the headquarters node monitors a group named Group 2. This configuration can run the workflow policies that it requires and meet the restriction of one Workflow Monitor Agent for one group. Multiple Workflow Monitor Agent and Workflow Action Agent processes can monitor different groups that run at the same time. Starting Workflow Monitor Agent
To start the Workflow Monitor Agent, you begin by creating a separate server component for each Workflow Monitor Agent server task. You then start Workflow Monitor Agent from the Server Manager command line interface. Creating a New Workflow Monitor Agent Server Component
In releases prior to Siebel CRM version 7.0, you can start Workflow Monitor Agent from the Server Tasks view in the Server Manager user interface. Beginning with Siebel version 7.0, you must start Workflow Monitor Agent from the Server Manager command line interface. To create a new workflow monitor agent server component
- In the Siebel client, navigate to the Administration-Server Configuration screen, Enterprises, and then the Component Definitions view.
- In the Component Definitions list, add a new record using values from the following table.
|
|
Name |
Name of the component. |
Component Type |
Workflow Monitor Agent |
Component Group |
Choose an existing component group. |
Description |
Description of the component. |
Alias |
Alias for the component. The alias cannot contain blank spaces. |
- Save the record.
- In the Component Parameters list, choose the Group Name parameter record, and then enter the name of the workflow policy group for which this component handles requests.
- Optional. Make more changes to the component parameters.
For more information, see Setting the Parameters of the Workflow Monitor Agent.
- In the Component Parameters list, choose the Default Tasks parameter, and then set the Value to 1.
This server component starts up and shuts down with the Siebel Server. Do not set Default Tasks to a value greater than 1. If you set Default Tasks to a value greater than 1, then undesirable behavior might result, such as multiple server tasks that start for the same workflow group.
- In the Component Definitions list, click Menu, and then click Enable Component Definition.
Siebel CRM changes the definition state from Creating to Active.
- Stop, and then restart the Siebel Server so that this instance for this server component goes into effect.
If you change a component parameter, then you must stop, and then restart the server component. Also, you must create a separate Workflow Monitor Agent instance for each workflow policy group.
- Start the Workflow Monitor Agent.
For more information, see Starting Workflow Monitor Agent.
Starting the Workflow Monitor Agent
You use the Server Manager command line to start the Workflow Monitor Agent. CAUTION: If a Workflow Process Manager server task fails, and if more server tasks start that also fail, then Workflow Monitor Agent exits with error after only one violation. This situation can result in Workflow Monitor Agent starting more server tasks that are not required when the Workflow Process Manager server task fails. To avoid this situation, it is recommended that you stop, and then restart Workflow Process Manager.
For more information, see Setting the Parameters of the Workflow Monitor Agent. For more information about using the Siebel Server Manager Command Line Interface, see Siebel System Administration Guide. To start the workflow monitor agent
- Start the Server Manager. Enter the following command in the Server Manager command line:
srvrmgr /g gateway_server_address /s Siebel_Server_name /e enterprise_server_name /u server_administrator_user_name /p server_administrator_password
- Start a new Workflow Monitor Agent server task in background mode. Enter the following command:
start task for component WorkMon with SleepTime=time,GroupName=group_name
- Optional. Start a new Workflow Monitor Agent server task to run in batch to process a Batch policy. Enter the following command:
start task for component WorkMon with GroupName=group_name, BatchMode=Y
You must create a separate server component instance for each Workflow Monitor Agent server task.
Stopping or Restarting a Component of the Workflow Monitor Agent
You can stop or restart a Workflow Monitor Agent component. To stop or restart a component of the workflow monitor agent
- In the Siebel client, navigate to the Administration-Server Management screen, and then the Components view.
- Choose the component, and then click Shutdown or Startup.
If you make changes to component parameters, then you must stop, and then restart the component. Also, you must define a separate instance of the Workflow Monitor Agent for each workflow policy group. Keeping Definitions for Workflow Monitor Agent Current
Workflow Monitor Agent and Workflow Action Agent read workflow configurations from the Siebel database. If you use Siebel Tools to modify a workflow policy object, column, or program in the local database, then you must check these objects into the Siebel database. If you do not do this, then Workflow Monitor Agent and Workflow Action Agent possess no knowledge about these modifications. Also, you must restart Workflow Monitor Agent and Workflow Action Agent in the following situations:
- After using Siebel Tools to modify an object, column, or program for a workflow policy
- After using the workflow administration views in the Siebel client to modify a workflow action
If you do not restart Workflow Monitor Agent and Workflow Action Agent, then the modifications do not go into effect until Siebel CRM reloads the workflow policies, as defined in the Reload Policy parameter. Because the Reload Policy parameter is set to 600 seconds by default, in most situations 10 minutes elapse before the modifications go into effect if you do not perform a restart. If you modify a workflow process, then it is not necessary to restart the Workflow Process Manager. For more information, see Modifying a Workflow Process. For more information about checking in and checking out objects, see Using Siebel Tools. To keep definitions for Workflow Monitor Agent current
- Check in any modifications that you make to a workflow policy object, column, or program into the Siebel database. Use the Project check in feature in Siebel Tools.
- If necessary, restart Workflow Monitor Agent and Workflow Action Agent.
For more information, see Stopping or Restarting a Component of the Workflow Monitor Agent.
Setting the Parameters of the Workflow Monitor Agent
Table 68 describes parameters that you can set for the Workflow Monitor Agent in the Server Manager command line interface.
Table 68. Parameters of the Workflow Monitor Agent
|
|
|
|
ActionAgent |
Use Action Agent |
Determines if the Action Agent runs with Monitor Agent. If set to the default FALSE, then the Workflow Action Agent server component starts in the Workflow Monitor Agent and the Workflow Monitor Agent then runs actions. Several factors apply when configuring Use Action Agent. For more information, see Setting the Use Action Agent Parameter. |
FALSE |
ActionInterval |
Action Interval |
Specifies the action execution interval in seconds. This parameter determines when Siebel CRM runs actions for a workflow policy on the row of a base table. This parameter limits the number of times that Siebel CRM runs an action if a row continues to go in and out of a matching state. If the same record repeatedly meets the same workflow policy before the action interval expires, then Siebel CRM removes the record from the S_ESCL_REQ table and does not perform the action again. For more information, see Tables That Workflow Monitor Agent Uses. The default value is 3600 seconds. If you use this parameter, then you must set the value to greater than 0 (zero) or unexpected behavior might result. |
3600 |
BatchMode |
Processes the batch policies |
Determines if Monitor Agent runs in batch mode. If the BatchMode parameter is:
- TRUE. Siebel CRM evaluates only those policies with the Batch Flag set to TRUE. Workflow Monitor Agent runs one time. It processes records in the table, and then exits.
- FALSE. Siebel CRM evaluates only those policies with the Batch Flag set to FALSE.
|
FALSE |
CheckLogCacheSz |
Cache size of Policy violations |
Specifies the number of workflow policies that Siebel CRM stores in the cache. To determine if an action already started, Siebel CRM uses the ROW_ID and RULE_ID in the map or cache. The Workflow Monitor examines the S_ESCL_LOG table for policy violations for the same BT_ROW_ID and RULE_ID. |
100 |
DeleteSize |
Request delete size |
Specifies the number of records to commit at a time. The minimum value is 1. If the Workflow Monitor encounters a deadlock, then you can reduce the default value from 500 to 125 with minimal performance degradation. To avoid a call stack error, do not set the DeleteSize parameter to zero. |
500 |
GenReqRetry |
Number of seconds to retry |
Specifies the number of seconds to retry sending a Generic Request message. |
120 |
GroupName |
Group Name |
Required. Specifies the workflow policy group on which Monitor Agent works. |
Not applicable |
IgnoreError |
Ignore errors |
Determines if Siebel CRM ignores errors while it processes a request. By default, the Workflow Monitor Agent and Workflow Action Agent do not ignore errors that occur while processing a request. If an error occurs, and if the IgnoreError parameter is:
- TRUE. The Workflow Monitor Agent logs the error, deletes the request, and then continues processing the next request.
- FALSE. The Workflow Monitor Agent exits and sends an email to the mail Id that you define in the Mailing Address parameter.
It is recommended that you set the IgnoreError parameter to FALSE. |
FALSE |
KeepLogDays |
Number of days to keep violation information |
Specifies the number of days of violation information that Siebel CRM retains in the log. It removes log information that is older than the value in the KeepLogDays parameter. To prevent Siebel CRM from removing this log information, you can set this value to 0. For more information, see Setting the Keep Log Days Parameter. |
30 |
LastUsrCacheSz |
Cache size of last user information |
Specifies the number of last user information items that Siebel CRM caches on the Siebel Server. If running an action, then the information about the last user who modified the row of the base table is available as a token substitution in the program arguments. To improve throughput performance of actions that Siebel CRM runs, it can cache this information. |
100 |
MailServer |
Mail Server |
Specifies the name of the email server where Siebel CRM sends an email to notify you that an abnormal termination occurred. |
Not applicable |
MailTo |
Mailing Address |
Specifies the email address where Siebel CRM sends an email if an abnormal termination occurred. If a Workflow Agent process exits with an error, then Siebel CRM sends an email to the address that you specify. An error can result if an action fails to run, an object definition is not valid, and so on. |
Not applicable |
NumRetries |
Number of Retries |
Specifies the number of times Siebel CRM attempts a recovery. If Siebel CRM loses connectivity with the Siebel database, then the NumRetries parameter works in conjunction with the Retry Interval and Retry Up Time parameters to reconnect MTS or server components to the Siebel database. |
10000 |
ReloadPolicy |
Reload Policy |
Specifies the policy reload interval in seconds. It determines how frequently Siebel CRM reloads workflow policies. Reloading allows Siebel CRM to change the information that it displays and to incorporate changes that Generate Triggers creates. The default value is 600 seconds. |
600 |
Requests |
Requests Per Iteration |
Specifies the maximum number of requests that Siebel CRM reads for each iteration. It controls the maximum number of requests that Workflow Monitor Agent reads from the requests queue in one iteration. Between iterations, Workflow Monitor Agent does the following:
- Deletes processed requests and commits from the requests queue
- Optionally reloads policies from the Siebel database
- Determines if a shutdown request exists
- Optionally sleeps
|
5000 |
Sleep Time |
Sleep Time |
Specifies the time in seconds that the Workflow Agent server task sleeps after it polls for events and fulfills obligations to notify. This task waits for more requests when it sleeps. The default setting is 60 seconds so this task sleeps every one minute. It wakes up, processes requests, if there are any, and then sleeps. It does this work repeatedly. After the Workflow Agent process finishes, the Workflow Agent process stops polling until the time period that the Sleep Time parameter expires. This parameter affects the performance of the Workflow Agent process and the responsiveness of the Siebel Server. |
60 |
Setting the Use Action Agent Parameter
Table 69 describes when to set the Use Action Agent parameter.
Table 69. When to Set the Use Action Agent Parameter
When to Set Use Action Agent to False |
When to Set Use Action Agent to True |
In most situations, it is recommended that you start Workflow Monitor Agent with Use Action Agent set to False, which is the default setting. If Use Action Agent is False, then Workflow Monitor Agent monitors the situation and runs actions. Some possible actions that run include workflow processes, workflow programs, and email programs. If you start Workflow Action Agent to run actions when Use Action Agent is True, and if the action is running a workflow process, then Siebel CRM might encounter an access violation error and Workflow Action Agent might fail. |
If Siebel CRM runs an action that includes email consolidation, then it is recommended that you set Use Action Agent set to True. If you use email consolidation, and if Use Action Agent is True, then you must start Workflow Action Agent separately. |
Setting the Keep Log Days Parameter
If you set the KeepLogDays parameter to 0, then the Workflow Monitor Agent does not remove data from the S_ESCL_LOG table. If you set this parameter to 0, then it is recommended that you monitor the size of the S_ESCL_LOG table. The size of this table affects performance. Use this parameter judiciously. Infrequent cleaning of the S_ESCL_LOG table can cause slow performance. You must determine how often to start Workflow Monitor Agent using KeepLogDays, and then restart Workflow Monitor Agent with a setting of 0 for this parameter.
|
