Bookshelf Home | Contents | Index | Search | PDF |
Siebel Business Process Designer Administration Guide for Financial Services > 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
- From the application-level menu, choose View > Site Map > Server Administration > Enterprise Configuration.
The Enterprise Configuration view appears.
- Click the Component Definitions tab.
Two Component Definitions lists appear.
- From the upper Component Definitions list menu, choose New Record.
A new record appears.
- Complete the fields described in Table 86:
- From the upper Component Definitions list 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
- In the upper Component Definitions list, perform a query for the component definition.
- Optional. You may make additional changes to the component parameters. For a description of Workflow Monitor Agent parameters, see Table 87.
- From the upper Component Definitions list menu, choose Enable Component Definition.
The definition state changes from "Creating" to "Active."
- Restart the Siebel server.
Your changes take effect.
To stop or restart a Workflow Monitor Agent component
- From the application-level menu, choose View > Site Map.
- Click Server Administration, then click Servers.
The Servers view appears.
- Click the Server Components tab.
- 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
- Start the server manager by entering:
srvrmgr /g <gateway server address> /s <Siebel server name> /e <enterprise server name> /u <server administrator username> /p <server administrator password>
- Start a new Workflow Monitor Agent task in background mode by entering:
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
- Navigate to View > Site Map >Server Administration >Enterprise Operations.
- In the Component Request view, click New.
- From the Component/Job picklist, select the name of the server component defined for this Workflow Monitor Agent task.
- In the Component Request Parameters applet, click New.
Specify the parameters for the Workflow Monitor Agent. See Table 87 for a list of parameters.
- Click Submit Request on the applet menu in the Component Requests Form to begin Workflow Action Agent task.
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 87 shows Workflow Monitor Agent parameters.
Table 87. 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 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. 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. See Monitoring and Tuning Performance for more information. 60NOTE: You can separate the processes for load balancing or run one process for ease of testing.
Bookshelf Home | Contents | Index | Search | PDF |
Siebel Business Process Designer Administration Guide for Financial Services Published: 22 May 2003 |