Siebel Business Process Designer Administration Guide > Workflow Policies Server Administration > Working with Workflow Monitor Agent >

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 can 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.

NOTE:  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

To create a Workflow Monitor Agent component definition

  1. From the application-level menu, choose View > Site Map > Server Administration > Enterprise Configuration.
  2. The Enterprise Configuration view appears.

  3. Click the Component Definitions tab.
  4. Two Component Definitions lists appear.

  5. From the upper Component Definitions list menu, choose New Record.
  6. A new record appears.

  7. Complete the fields described in Table 84:

Table 84. Component Definitions Fields
Name of the component
Component Type
Component Group
Select an existing component group
Description of the component
Alias for the component. The alias can not contain blank spaces.

  1. From the upper Component Definitions list menu, choose Save Record.
  2. The component definition is saved. To view the definition, you must perform a query.

To set parameters and activate a Workflow Monitor Agent component definition

  1. In the upper Component Definitions list, perform a query for the component definition.
  2. Optional. You may make additional changes to the component parameters. For a description of Workflow Monitor Agent parameters, see Table 85.
  3. From the upper Component Definitions list menu, choose Enable Component Definition.
  4. The definition state changes from "Creating" to "Active."

  5. Restart the Siebel server.
  6. Your changes take effect.

To stop or restart a Workflow Monitor Agent component

  1. From the application-level menu, choose View > Site Map.
  2. Click Server Administration, then click Servers.
  3. The Servers view appears.

  4. Click the Server Components tab.
  5. Select the component you would like to stop or restart, then click Shutdown or Startup.

To start Workflow Monitor Agent using the Server Manager command-line interface

  1. Start the server manager by entering:
  2. srvrmgr /g <gateway server address> /s <Siebel server name> /e <enterprise server name> /u <server administrator username> /p <server administrator password>

  3. Start a new Workflow Monitor Agent task in background mode by entering:
  4. start task for component WorkMon with SleepTime=<time>,GroupName=<group name>

    For more information, see Siebel Server Administration Guide.

You can start the Workflow Monitor Agent from the command line. For more information, see Siebel Server Administration Guide.

NOTE:  You will need to create a separate server component definition for each Workflow Monitor Agent task.

To run the Workflow Monitor Agent task

  1. Navigate to View > Site Map >Server Administration >Enterprise Operations.
  2. In the Component Request view, click New.
  3. From the Component/Job picklist, select the name of the server component defined for this Workflow Monitor Agent task.
  4. In the Component Request Parameters applet, click New.
  5. Specify the parameters for the Workflow Monitor Agent. See Table 85 for a list of parameters.

  6. Click Submit Request on the applet menu in the Component Requests Form to begin Workflow Action Agent task.
  7. NOTE:  You should only run one instance of Workflow Monitor and Workflow Action Agent for a given workflow group. For example, you can start only one instance for the "Sales" group at a specific time. However, you are allowed to have multiple Workflow Monitor and Workflow Action Agent processes for different groups running at the same time.

Table 85 shows Workflow Monitor Agent parameters.

Table 85. WorkMon Command-Line Interface Parameters
Parameter Name
Display Name
Default Value
Use Action Agent
Determines if 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.
You must start Workflow Action Agent separately when using email consolidation and when the parameter Use Action Agent is set to TRUE.
Action Interval
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 is to limit 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 will be removed from the S_ESCL_REQ table and the action will not be performed again.
Note: The default is 3600 seconds. If this parameter is used, the value must be greater than 0 (zero) or unexpected behavior may result.
Processes the batch policies
Determines if 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 will be evaluated. When FALSE, only the policies that have the Batch flag set to FALSE will be evaluated.
Note that when starting with Batch Mode set to TRUE, Workflow Monitor Agent will run once; that is, it will go through all records in the table and then exit out.
Cache size of Policy violations
Number of policy violations to store in cache.
Request delete size
This indicates the number of records to commit at a time. The minimum is 1. If Workflow Monitor encounters deadlocks, you may 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.
Number of seconds to retry
Number of seconds to retry sending a Generic Request message.
Group Name
Required. Workflow policy group that Monitor Agent works on.
Ignore errors
Ignore errors while processing requests. By default, the Workflow Monitor and Action agents will not ignore errors that occur while processing the requests. If an error is encountered, the agent processes will log the error condition, delete the request, and continue working. By setting this argument to FALSE, the agent processes will 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 will be ignored. Whereas, if Ignore Errors is set to FALSE, the agent stops and exits with the error. It is recommended that you set Ignore Errors to FALSE so that valid errors are not ignored.
Number of days to keep violation information
Number of days worth of violation information that should be retained.
Sets the number of days log information is stored. Log information older than the number of days set is automatically removed from the system. This value can be set to 0 to prevent the purging of this log information.
Cache size of last user information
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.
Mail Server
Name of email server to send notification of abnormal termination.
Mailing Address
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 on.
Reload Policy
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.
Requests per iteration
Maximum number of requests read per 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 between-iteration steps.
Sleep Time
Sleep Time
The time in seconds that the Workflow Agent process "sleeps" after it has polled for events and fulfilled all obligations to notify. Once it has completed 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. See Monitoring and Tuning Performance for more information.

NOTE:  You can separate the processes for load balancing or run one process for ease of testing.

 Siebel Business Process Designer Administration Guide 
 Published: 29 May 2003