Bookshelf v8.0: Executing a Workflow Policy with Workflow Monitor Agent

Workflow Monitor Agent checks when the conditions of a workflow policy is met, and executes actions once conditions are met. To execute your workflow policies, you must start Workflow Monitor Agent. You start and stop the Workflow Monitor Agent task in the Administration-Server views.

What Workflow Monitor Agent Does

Workflow Monitor Agent executes several server processes that monitor the Siebel database. Tasks performed by Workflow Monitor Agent include:

If you set Action Agent to True, and if Workmon determines that the request in the S_ESCL_REQ table has no duration defined in the policy, Workmon takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table.

If Workmon determines that the request has a time element that must be met, the request is sent to the S_ESCL_STATE table along with the expiration time. The request stays in the S_ESCL_STATE table until the expiration time is met, or the request is removed because the conditions of the policy are no longer met. Workmon evaluates each of the requests that remains in the S_ESCL_STATE table for a time duration match or to determine if the condition still matches in the S_ESCL_STATE table. If you set Action Agent to True, then as each match occurs WorkMon takes direct action and logs an entry into the S_ESCL_LOG table or sends it to the S_ESCL_ACTN_REQ table.

NOTE: If a workflow policy has a specified duration, the duration time is calculated from the time WorkMon detects that the row is in violation of the policy, not from the time the row was inserted into the S_ESCL_REQ table. For example, if you create a policy and set the duration as one week, but then WorkMon is not started until several days after Generate Triggers is run, the policy action fires one week from when WorkMon is started, not one week from when the policy is created or Generate Triggers is run.

When the request for an action is made to the S_ESCL_ACTN_REQ table, Workflow Action Agent executes the action and logs an entry into the S_ESCL_LOG table.

About S_ESCL_REQ.REQ_ID

S_ESCL_REQ.REQ_ID can hold up to 9 digits, so the maximum value allowed is 999,999,999. Because the S_ESCL_REQ_S sequence does not have an upper boundary, the sequence for S_ESCL_REQ.REQ_ID can potentially generate a number greater than the maximum of 9 digits allowed, causing an overflow. To avoid this, it is recommended you perform one of the following actions:

As a separate issue, you might encounter a message similar to Status: Deleting requests ([a numeric identifier]).

This message does not indicate the number of rows WorkMon is deleting. The numeric identifier indicates the REQ_ID from S_ESCL_REQ, which is generated by the database to uniquely number the rows in the database. For example, the ways in which REQ_ID is generated include:

Checking Modifications Into the Local Database

The Workflow Monitor Agent and Workflow Action Agent read workflow configurations from the server 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 server database. Otherwise, workflow monitor agent and workflow action agent have no knowledge about these modifications.

Also, you should restart workflow monitor agent and workflow action agent after modifying a workflow policy object, column, or program through Siebel Tools, or after modifying a workflow action through the workflow administration views in the Siebel client.

If you do not restart workflow monitor agent and workflow action agent, the modifications do not take effect until policies are reloaded, as specified in the Reload Policy parameter. Since the Reload Policy parameter is set to 600 seconds by default, in most cases 10 minutes elapse before the modifications take effect if you do not perform a restart.

It is not necessary to restart the Workflow Process Manager when modifying a workflow process. For more information, see Modifying a Workflow Process.

Using Workflow Monitor Agent

Before you start workflow monitor agent, you must create a separate server component definition for each workflow monitor agent task. You start workflow monitor agent from the server manager command-line interface.

Replication and Workflow Monitor Agent

Within the entire enterprise architecture of a Siebel deployment, there can be only one workflow monitor agent monitoring a particular workflow group.

For example, a regional node can be running a workflow monitor agent that monitors a group called Group 1. Meanwhile, in the headquarters, there is another WorkMon running, which monitors a group called Group 2. In this way, the organization is able to run workflow policies where needed, while working with the restriction of one WorkMon for one group. You cannot run more than one instance of workflow monitor agent and workflow action agent for a particular workflow group. However, you are allowed to have multiple workflow monitor agent and workflow action agent processes for different groups running at the same time.

Starting Workflow Monitor Agent

This topic describes procedures you perform when using workflow monitor agent. To start this predefined component, you must first create a new workflow monitor agent component definition.

In releases prior to Siebel version 7.0, you can start workflow monitor agent from the Server Tasks view in the Server Manager user interface. This is no longer the case. Starting with Siebel version 7.0, you must start workflow monitor agent from the Server Manager command-line interface.

NOTE: Whenever you make a change to a component parameter, the component must be stopped and restarted for the changes to take effect. Also, you must define a Workflow Monitor Agent component definition for each Workflow Policy Group.

You must create a separate server component definition for each Workflow Monitor Agent task.

CAUTION: If a Workflow Process Manager task fails, and more tasks are started that also fail, then Workflow Monitor Agent exits with error after only one violation. This can result in Workflow Monitor Agent starting more, unneeded tasks when the WfProcMgr task fails. To avoid this condition stop, then restart wfprocmgr.

NOTE: When you make changes to the parameters of the component, the component must be stopped and restarted for the changes to take effect. Also, you must define a Workflow Monitor Agent component definition for each Workflow Policy Group.

Workflow Monitor Agent Command-Line Interface Parameters

Table 73 describes parameters that can be set by using the Workflow Monitor Agent command-line interface.

Table 73. Description of Parameters for WorkMon Command-Line Interface
Parameter Name	Display Name	Usage	Default Value
ActionAgent	Use Action Agent	Specify whether the Action Agent is automatically run with Monitor Agent. If set to FALSE (the default setting), the Workflow Action Agent server component starts within Workflow Monitor Agent, and actions are then executed by Workflow Monitor Agent. Several conditions apply when configuring Use Action Agent. For more information, see Setting the Use Action Agent Parameter	FALSE
ActionInterval	Action Interval	Define the action execution interval in seconds. This argument determines when actions for a given policy are executed again on a given base table row. The purpose of this argument limits the number of times actions are executed if a row keeps going in and out of a matching condition. In other words, if the same record repeatedly violates the same policy before the action interval expires, the record is removed from the S_ESCL_REQ table and the action is not performed again. Note: The default is 3600 seconds. If this parameter is used, the value must be greater than 0 (zero) or unexpected behavior can result.	3600
BatchMode	Processes the batch policies	Specify whether Monitor Agent is running in batch mode. When the value is set to TRUE, only the policies that have the Batch flag set to TRUE are evaluated. When FALSE, only the policies that have the Batch flag set to FALSE are evaluated. Note that when starting with BatchMode set to TRUE, Workflow Monitor Agent is run once. That is, it processes records in the table then exits.	FALSE
CheckLogCacheSz	Cache size of Policy violations	Define the number of policy violations to store in cache. This parameter determines how many violated policies can be stored in the cache. Based on the presence of the ROW_ID and RULE_ID in the map/cache, the cache determines whether or not an action is already initiated. The Workflow Monitor checks S_ESCL_LOG for policy violations for the same BT_ROW_ID and RULE_ID.	100
DeleteSize	Request delete size	Define the number of records to commit at a time. The minimum is 1. If Workflow Monitor encounters deadlocks, you can reduce the default to 125 with minimal performance degradation. Note: to avoid call stack errors, do not set the Request Delete Size value to zero.	500
GenReqRetry	Number of seconds to retry	Define the number of seconds to retry sending a Generic Request message.	120
GroupName	Group Name	Required. Define the workflow policy group that Monitor Agent works on.	(This cell is intentionally empty.)
IgnoreError	Ignore errors	Specify whether to ignore errors while processing requests. By default, the Workflow Monitor and Action agents do not ignore errors that occur while processing the requests. If Ignore Errors is set to TRUE and an error is encountered, the agent processes log the error condition, delete the request, then continue working. By setting this argument to FALSE, the agent processes exit on an error and send an email message to the mail ID specified by the Mailing Address argument. When running Workflow with Ignore Errors=TRUE, note that valid errors are ignored. Whereas, if Ignore Errors is set to FALSE, the agent stops and exits with the error. NOTE: It is recommended that you set Ignore Errors to FALSE so that valid errors are not ignored.	FALSE
KeepLogDays	Number of days to keep violation information	Define the number of days worth of violation information to be retained. Sets the number of days log information is stored. Log information older than the number of days set is automatically removed. This value can be set to 0 to prevent the purging of this log information. For more information, see KeepLogDays Parameter and Workflow Monitor Agent.	30
LastUsrCacheSz	Cache size of last user information	Define the number of last user information items to cache. When executing actions, the information about the last user to modify the base table row is available as a token substitution in the program arguments. By caching this information in the server, the throughput performance of executing actions can potentially increase.	100
MailServer	Mail Server	Define the name of email server to send notification of abnormal termination.	(This cell is intentionally empty.)
MailTo	Mailing Address	Define the mail address to review notification of abnormal termination. Mail to [mail ID] if a Workflow Agent process exits with an error condition. An error can be caused by the failure of an action to execute, invalid object definitions, and so forth.	(This cell is intentionally empty.)
NumRetries	Number of Retries	Define the number of retries for recovery. This parameter works with the Retry Interval and Retry Up Time parameters to reconnect MTS or Siebel Server components to the database if database connectivity is lost.	10000
ReloadPolicy	Reload Policy	Define the policy reload interval in seconds. This argument defines the frequency that policies are reloaded into the engine. This allows changes to be made on the screens and with the Generate Triggers component. The engine acts on the changes within some time frame. The default is 600 seconds.	600
Requests	Requests Per Iteration	Define the maximum number of requests read for each iteration. This controls the maximum number of requests WorkMon reads from the requests queue within one iteration. Between iterations WorkMon deletes processed requests from the requests queue and commits, optionally reloads policies from the database, checks for shutdown request, and optionally sleeps. In other words, you can think of the Requests Per Iteration parameter as a way to control the maximum amount of work WorkMon performs before taking these steps between iterations.	5000
Sleep Time	Sleep Time	Define the time in seconds that the Workflow Agent process sleeps after it has polled for events and fulfilled obligations to notify. Once the Workflow Agent process has finished its obligations, the Workflow Agent process stops polling for the time period set by the sleep interval. This parameter affects both the performance of the Workflow Agent process and the responsiveness of the application server. For more information, see Sleep Time Parameter and Workflow Monitor Agent.	60

Setting the Use Action Agent Parameter

Sleep Time Parameter and Workflow Monitor Agent

You can increase the Sleep Time to adjust the processing frequency, because the WorkMon task waits for more requests when it goes to sleep. By default, the task sleeps every one minute (the default setting is 60 seconds). The WorkMon task wakes up, processes requests (if there are any), then goes back to sleep. WorkMon does this repeatedly.

KeepLogDays Parameter and Workflow Monitor Agent

If the Number of Days to Keep Violation Information parameter is set to 0, then WorkMon does not purge from S_ESCL_LOG. If you set this parameter to 0, then monitor the size of S_ESCL_LOG, because the size of this table affects performance. Use this parameter judiciously.

Because infrequent cleaning of S_ESCL_LOG can lead to slow performance, decide how often you need to start WorkMon using KeepLogDays, then restart WorkMon with a setting of 0 for this parameter.

Siebel Business Process Framework: Workflow Guide		Copyright © 2008, Oracle. All rights reserved.

Executing a Workflow Policy with Workflow Monitor Agent

About Workflow Monitor Agent