Siebel Business Process Designer Administration Guide > Workflow Policies > About Workflow Policies Server Administration >

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

The following tasks are involved in starting Workflow Monitor Agent:

Table 67 shows Workflow Monitor Agent parameters.

To create a Workflow Monitor Agent component definition

  1. In the Siebel client, from the application-level menu, choose Navigate > Site Map > Administration - Server Configuration > Enterprises > Component Definitions.
  2. In the Component Definitions list, click New.
  3. Complete the fields described in Table 66:
Table 66.  Component Definitions Fields
Field
Description

Name

Name of the component

Component Type

WorkMon

Component Group

Select an existing component group

Description

Description of the component

Alias

Alias for the component. The alias can not contain blank spaces.

  1. From the applet-level menu, choose Save Record.

    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 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 67.
  3. From the Component Definitions list applet-level menu, choose Enable Component Definition.

    The definition state changes from "Creating" to "Active."

  4. Restart the Siebel server.

    Your changes take effect.

To stop or restart a Workflow Monitor Agent component

  1. From the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs.
  2. In the Jobs list, click New.
  3. From the link bar, click Servers.
  4. Click the 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:

    srvrmgr /g <Siebel Gateway Name Server address> /s <Siebel server name> /e <enterprise server name> /u <server administrator username> /p <server administrator password>

  2. Start a new Workflow Monitor Agent task in background mode by entering:

    start task for component WorkMon with SleepTime=<time>,GroupName=<group name>

You can start the Workflow Monitor Agent from the command line.

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. From the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs.
  2. In the Jobs list, click New.
  3. From the Component/Job drop-down list, select the name of the server component defined for this Workflow Monitor Agent task.
  4. In the Job Parameters list, click New.

    Specify the parameters for the Workflow Monitor Agent. See Table 67 for a list of parameters.

  5. In the Job Detail form applet, from the applet-level menu, select Start Job to begin Workflow Action Agent task.

    NOTE:  Run only 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 67 shows Workflow Monitor Agent parameters.

Table 67.  WorkMon Command-Line Interface Parameters
Parameter Name
Display Name
Description
Default Value

ActionAgent

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.

FALSE

ActionInterval

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.

3600

BatchMode

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.

FALSE

CheckLogCacheSz

Cache size of Policy violations

Number of policy violations to store in cache.

100

DeleteSize

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.

500

GenReqRetry

Number of seconds to retry

Number of seconds to retry sending a Generic Request message.

120

GroupName

Group Name

Required. Workflow policy group that Monitor Agent works on.

 

IgnoreError

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 Ignore Errors is set to TRUE and 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.

FALSE

KeepLogDays

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.

30

LastUsrCacheSz

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.

100

MailServer

Mail Server

Name of email server to send notification of abnormal termination.

 

MailTo

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.

 

NumRetries

Number of Retries

Number of retries for recovery. This parameter works with the Retry Interval and Retry Up Time parameters to reconnect MTS or Siebel Server mode components to the database if database connectivity has been lost.

10000

ReloadPolicy

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.

600

Requests

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.

5000

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.

60

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

Siebel Business Process Designer Administration Guide