16Administering, Testing, and Migrating Workflow Policies
Administering, Testing, and Migrating Workflow Policies
This chapter describes how to administer, test, and migrate workflow policies. It includes the following topics:
Administering Workflow Policies
This topic describes how to administer workflow policies. It includes the following topics:
Confirming Workflow Policies Installation
In this topic, you make sure workflow policies are installed correctly. You install the Workflow Policies module when you install the Siebel Server and the Siebel client. You use your license key to activate Workflow Policies. This topic describes only how to make sure Workflow Policies is correctly installed. For information about the installation process, see the installation guide for the operating system you are using.
To use Workflow Policies, make sure server components, including Workflow Management, Siebel Tools, and the Siebel client, are installed.
Confirming the Repository Setting for Workflow Policies
Siebel CRM uses the cfg file in the Siebel client to configure the Workflow Policies module. You must make sure the DockRepositoryName parameter of this cfg file references the correct repository name.
Confirming Siebel Workflow is Set Up for Workflow Policies
You must make sure that your license key includes Siebel Workflow. You must also make sure you installed the Siebel Server correctly. Siebel Workflow runs as a server component on the Siebel Server.
To confirm Siebel Workflow is set up for workflow policies
Log in to the Siebel client as the Siebel administrator.
Navigate to the Administration-Business Process screen.
In the list of views, verify that the Policies, Policy Groups, and so on, are visible. This visibility indicates that your license key is correct.
Log in to a Siebel client that is configured to manage the server component groups, navigate to the Administration-Server Management screen, Servers, and then the Component Groups view.
Make sure the Workflow Management component group is active.
Administering Database Triggers on the Workflow Policy Server
This topic describes how to administer database triggers on the workflow policy server. It includes the following topics:
Overview of Creating Database Triggers
The Generate Trigger (GenTrig) server component on the Siebel Server allows you to create database triggers. Workflow Policies uses these triggers to identify the records that match workflow policy conditions. You can run Generate Triggers if you must do one of the following:
Define or delete new workflow policies, including assignment policies, except for workflow policies with the Batch Flag property set to TRUE.
Amend workflow policy conditions or policy criteria.
Change activation or expiration dates of policies, including assignment policies.
How Generate Triggers Works with a Workflow Policy That Contains Multiple Conditions
If a workflow policy includes two or more workflow policy conditions, then Generate Triggers uses OR logic instead of AND logic.
| Property | Condition 1 | Condition 2 |
|---|---|---|
Condition Field |
Account Modification Num |
Account Last Update By |
Operation |
> |
<> |
Value |
0 |
0-1 |
Siebel CRM can use multiple database triggers for multiple workflow policy conditions in one workflow policy. This configuration keeps Generate Triggers functionality and Workflow Monitor Agent functionality separate:
Generate Triggers monitors changes that Siebel CRM makes to database records and inserts records in tables that are specific to a workflow policy.
Workflow Monitor Agent evaluates conditions, determines if the conditions that are associated with the rule are met, and runs the actions that are associated with the workflow policy.
Using an AND Condition with Multiple Database Triggers
If multiple workflow policy conditions exist in a workflow policy, then you cannot use an AND condition between database triggers. Generate Triggers can only monitor database changes. Database changes that meet different conditions might not be concurrent. Using an AND condition can cause Generate Triggers to miss many conditions.
For example, assume a workflow policy contains the following workflow policy conditions:
SR area is Network
Activity Priority is 1-ASAP
In this situation, Siebel CRM creates the following database triggers:
One database trigger monitors a service request that Siebel CRM creates or updates, and then determines if the area equals Network.
One database trigger monitors an activity that Siebel CRM creates or updates, and then determines if the Priority equals 1-ASAP.
If you use an AND database trigger, and if a user creates a service request that does not include an activity, then Siebel CRM does not run the database trigger because the activity does not exist. If the user then adds an activity to the service request, then no database trigger runs because the service request does not change. The AND condition causes Siebel CRM to miss this violation. If you use an OR condition, and if Workflow Monitor Agent evaluates the workflow policy condition even though multiple violations exist in the S_ESCL_REQ table, then the Workflow Monitor Agent only processes one request because the other requests do not evaluate to TRUE. For more information, see Tables That Workflow Monitor Agent Uses.
Configuring Database Triggers
This topic describes how to configure the Generate Triggers server component. You can configure this server component from the Siebel client or from the command line. The Siebel client and the command line use the same parameters.
To configure database triggers
Make sure your environment can run the Generate Triggers server component:
Make sure the Siebel Server is installed.
Make sure the Siebel client can access the Siebel Server Administration screens.
For more information on installing Server Manager, see the installation guide for the operating system you are using.
In the Siebel client, navigate to the Administration-Server Management screen, and then the Jobs view.
In the Jobs list, click New.
In the drop-down list for the Component/Job field, choose Generate Triggers.
This step creates a new line entry but does not start the Siebel Server task.
In the Job Parameters list, click New to modify component specific parameters, using values from the following table.
Name Value Description Remove
TRUE or FALSE (default)
To create DROP TRIGGER statements to clean up the database triggers, set to TRUE. Remove does not create CREATE TRIGGER statements.
Trigger File Name
Valid filename on the Siebel Server
Define the name and output location for the SQL script file. The default value is TRIGGER.SQL. Siebel CRM creates this file, and then places it in the root directory of the Siebel Server during installation.
EXEC
TRUE or FALSE
Set to TRUE to run the SQL script file automatically.
Set to FALSE to run the SQL script manually.
For more information, see Using the EXEC Parameter.
Mode
ALL, WORK, or ASGN
Use one of the following values:
ALL. Creates database triggers for workflow policies and Assignment Manager.
WORK. Creates database triggers only for workflow policies.
ASGN. Creates database triggers only for Assignment Manager.
Privileged User Name and Privileged User Password
Assigned Privileged User name and password
To make sure the user enters a Privileged User name and password, you can define the user name and password. Siebel CRM considers the Table Owner as a Privileged User. You can enter the Table Owner name and password in the Privileged User name and password fields.
For a description of generic and enterprise parameters, see Siebel System Administration Guide
Enter the Privileged User name and password.
In the Job Detail form, choose the applet-level menu, and then choose Start Job.
To view changes to the state, choose the applet-level menu, and then click Run Query to refresh the screen.
The Status field contains Success or Error after Siebel CRM refreshes the screen. You can view the log details.
If EXEC equals FALSE, then you must manually run the SQL script file.
For more information, see Manually Running the SQL Script File.
Using the EXEC Parameter
The EXEC parameter specifies how to run the SQL script file automatically according to one of the following values:
TRUE. Generate Triggers automatically creates the SQL script and applies it to your database.
FALSE. You must manually run the SQL script file
If one of the following situations is true, then you must set EXEC to FALSE, you must manually run the SQL script file, and you must not use the Generate Triggers server component. For more information, see Manually Running the SQL Script File:
You run a Sybase server with a Siebel or MS_SQL server. Setting EXEC to false prevents a connected user from receiving an error message when Siebel CRM creates database triggers. Make sure no users are logged in to the Siebel database before you create database triggers.
You define a large number of database triggers because too many workflow policies exist.
Manually Running the SQL Script File
After Generate Triggers finishes, if the EXEC parameter is FALSE, then you must run the SQL script file.
To manually run the SQL script file
Connect to the server that contains the database. Connect as the Siebel table owner. Use the SQL tool that your RDBMS vendor provides.
For example, use ISQL for Microsoft or SQL*Plus for Oracle.
Run the SQL script file that the Trigger File Name parameter references.
The default file name is TRIGGER.SQL. The default location of this file is the root directory of where you installed the Siebel Server. For example:
C:\siebsrvr\trigger.sql
If your environment uses an MS SQL server database, then you must run the trigger.sql script as the owner login, which is also known as the dbo login.
Make sure Siebel CRM reports no errors.
For example, assume you finish defining workflow policies in the Siebel client and must set the database triggers for these new policies. To set the file output name, you use Generate Triggers which creates a TRIGGER.SQL file that contains the database triggers that you modify or define in the test database. To create the database triggers in the Oracle database, you then run the following command in SQL*Plus:
SQL>@path\mytrig.sql
Oracle then indicates the successful creation of each database trigger. For information on the format that other databases require, see your database documentation.
Guidelines for Configuring Database Triggers
If you configure the Generate Triggers server component, then it is recommended that you use the following guidelines:
If you delete a workflow policy, then you must run Generate Triggers with the remove parameter set to TRUE, which removes every database trigger. You must then rerun Generate Triggers to reset the database triggers for the remaining workflow policies.
You must stop and restart the workflow monitor agents when you run Generate Triggers.
If you change a workflow policy condition or a workflow policy group, then you must rerun Generate Triggers. It is not necessary for you to rerun Generate Triggers if you change a workflow policy action. For more information, see Moving a Workflow Policy to a Different Group.
If you configuration uses a SQL Server, then make sure you set your default database correctly. To determine your default database, start the SQL Server Enterprise Manager, and then navigate to the SQL Server Machine name. Next, click Security, and then click LOGIN. The default database is listed to the right.
If you drop or recreate database task triggers, then you must start a new Workflow Monitor Agent, which refreshes the cache for this agent.
If a table name exceeds 18 characters, then Generate Triggers fails with an error that is similar to the following:
18 character limit, table_name trigger fail
If you run Generate Triggers, then the limit on table names that DB2 SQL uses results in limiting the database trigger name to 18 characters. Siebel CRM derives the database trigger name from the table name plus a suffix, such as U, I, D, U1, I1, D1, and so on.
Using Database Triggers with Remote Users
If a remote user synchronizes, then Siebel CRM incorporates changes in the Siebel database. For example, it updates account information in the S_ORG_EXT table. If you configure a workflow process that creates database triggers that compare changes in the Siebel database to a workflow policy condition, and if these changes affect this condition during synchronization, then the database triggers fire and Siebel CRM writes rows to the S_ESCL_REQ table. For more information, see Tables That Workflow Monitor Agent Uses.
Managing Database Triggers and Database Administration
It is important to make sure your database administrators are informed of database triggers that are active for a workflow process. A database update or insert event causes the database trigger to react, regardless of how the event runs. For example, if inserts to the S_SRV_REQ table exist, and if the Siebel database administrator performs a table export and import of these records, then the database triggers treat every record in the Siebel database as if it is a newly inserted record. This situation can result in Siebel CRM inappropriately modifying old records that were simply imported again.
Beginning with Siebel CRM version 8.1, the Generate Triggers server task requires the Privileged User Name and Password instead of Table Owner ID and Password.
Fixing Problems in the S_ESCL_REQ Table
If a database trigger runs on a workflow policy condition, then Siebel CRM inserts a record in the S_ESCL_REQ (escalation request) table. This table contains the rows that can cause a workflow policy to run. After the Workflow Monitor Agent processes a request, it removes the row from this table.
A database trigger does not include the logic that you define in a workflow policy condition. The conditions in the database trigger file might not be indicative of the workflow policies that are met. When Workflow Monitor Agent runs, the records in the S_ESCL_REQ table causes Siebel Workflow to evaluate the related workflow policy conditions. The database triggers exist only to trigger the Workflow Engine to examine the workflow policy conditions.
For more information about the S_ESCL_REQ table, see About the Workflow Monitor Agent.
To fix problems in the S_ESCL_REQ table
Use your database tools to monitor the size and efficiency of the table:
If the table is very large, then this situation indicates that Siebel CRM is monitoring too many workflow policies. To fix this problem, redefine the workflow policies so that they share the load.
If Siebel CRM monitors rows but does not remove them after the time interval finishes, then this situation might indicate that you deactivated a workflow policy but did not remove the database triggers that are associated with this policy. The database triggers continue to send data that no workflow policy works on. To fix this problem, remove the database triggers that are associated with the deactivated workflow policy.
If you create a new business component, then do not set the Table property to the S_ESCL_REQ table. A business component cannot reference the S_ESCL_REQ table.
Expire, rather than delete a workflow policy.
For more information, see Expiring a Workflow Policy.
Remove rows that belong to obsolete workflow policies.
For more information, see Deleting an Obsolete Workflow Policy.
Administering Email Manager and Page Manager
This topic describes how to administer email manager and page manager. It includes the following topics:
Guidelines for Configuring the Email Manager Server Component
Some workflow policy actions allow you to send an email to an individual. If you configure the Email Manager server component, then it is recommended that you use the following guidelines:
If you configure a workflow policy to send email through a mail system that is compliant with SMTP or POP3, then make sure that the SMTP or POP3 protocol is working properly on the network.
Make sure Email Manager is running. This server component is part of the Communications Management component group, which must be configured.
Make sure the profiles in the Communications Manager are configured to log in to a mail system that is compliant with SMTP or POP3. Email Manager uses these profiles. The Communications Outbound Manager verifies the profile.
Make sure the Mail Profile parameter is set to the name of the communication profile that Siebel CRM uses to send the email.
Date Format in an Email Message
The Siebel Server runs a workflow policy program. This server connects to Oracle through ODBC. As part of this process, Siebel CRM gets the required data from the Siebel database through this connection. The ODBC driver sets the date format in the email message that it returns, which might be different from the format that Oracle uses.
Setting Up the Communications Profile to Send Email Through a Workflow Process
This topic describes how to set up the communications profile to send email through a workflow process.
To set up the communications profile to send email through a workflow process
Configure CompGrp CommMgmt.
To send email through Siebel Workflow, you must define a communications profile. To create a new communications profile, you must configure CompGrp CommMgmt. For more information, see Siebel CTI Administration Guide.
In the Siebel client, navigate to the Administration-Communications screen, and then the Communications Drivers and Profiles view.
In the Communications Drivers list, query the Name field for the following communications driver:
Internet SMTP/POP3 Server
Click the Profiles view tab.
Create a new profile named profile_name.
In the Profile Parameters Overrides list, define parameters using values from the following table.
Parameter Description From Address
Define the email address of the sender for outbound communications.
POP3 Account Name
Define the account name for the POP3 mailbox from which to get inbound communications.
POP3 Account Password
Define the password for the POP3 mailbox account.
POP3 Server
Define the host name or IP address of the computer where the Internet POP3 server runs, as appropriate for your network configuration.
SMTP Server
Define the host name or IP address of the computer where the Internet SMTP server runs, as appropriate for your network configuration.
For details on these parameters, see Siebel CTI Administration Guide. After you define the communications profile, you must start the Email Manager server component. For more information, see Starting the Email Manager Server Component.
Starting the Email Manager Server Component
The Email Manager server component runs email actions if a workflow policy condition is met. You can start it from the command line or from the Server Configuration view in the Siebel client.
To start Email Manager from the command line
To start the Email Manager server task with the profile_name profile, enter the following command in the Server Manager command line:
start task for comp MailMgr with MailProfile=<Profile Name>
To start Email Manager from the server configuration view
In the Siebel client, navigate to the Administration-Server Configuration screen, Servers, and then the Components view.
In the Components list, locate the Email Manager server component.
In the Component Parameters list, set the Mail Profile field to Test.
Set the Default Tasks parameter to 1.
If the server component restarts, or if the Siebel Server services restart, then this step configures Siebel CRM to begin a server task for Email Manager.
How Outbound Communications Manager Sends Email
The Outbound Communications Manager uses the following sequence to send email messages:
If the workflow policy is met, then Workflow Monitor Agent inserts a record in the S_APSRVR_REQ table for workflow actions that call the Send Email workflow policy programs.
Email Manager picks up records from the S_APSRVR_REQ table, setting the status for each record from QUEUED to ACTIVE, and then to SUCCEEDED while the manager runs.
Siebel CRM calls the Outbound Communications Manager to log onto the profile_name profile.
To send emails to recipients, the Outbound Communications Manager uses the Send Message method of the Outbound Communications Manager business service.
Mail Profile Parameter
The Mail Profile parameter specifies the mail profile to use. You can set it in the Microsoft Windows Control Panel. It establishes the connection between Siebel CRM and the email system. If you do not define a profile, then Siebel CRM uses the default profile. The names must match exactly.
Starting the Page Manager Server Component
Some workflow policy actions allow you to send a page to an individual. To send a page, the Page Manager server component of the Siebel Server must be running. You can configure Siebel CRM to page an individual who uses an alphanumeric or numeric pager. To use Page Manager, the following items must be met:
The Siebel Server that runs Page Manager can access a local or network modem.
Page Manager is running. You must set several parameters for Page Manager that allow Siebel CRM to start Page Manager.
The Employee view includes the appropriate telephone numbers for paging. Siebel Workflow uses these numbers.
The regional configuration does not prefix the country code to the telephone number. Prefixing the country code can cause an error.
The PAGE_TYPE list of values parameters forces the page manager to accept an alphanumeric send, which displays the language and the value.
Alphanumeric paging is more reliable than numeric paging because a computer that resides at the company that provides pager services transmits the pager message. This situation is not true for numeric paging, where emulating key presses on a telephone sends the pager message. It can be difficult to detect a failure in sending a numeric page.
Page Manager uses the Telocator Alphanumeric Protocol (TAP) protocol for alphanumeric paging. To determine the phone number in which to send your alphanumeric page, consult with the company that provides your pager services.
The Server Administration screen lists the parameters that affect how Page Manager interacts with the modem. The default values that this screen lists are the default values for a Hayes compatible modem. You must make sure these values are compatible with the modem that your environment uses.
To start the Page Manager server component
In the Siebel client, navigate to the Administration-Server Management screen, and then the Jobs view.
In the Jobs list, click New.
In the Component/Job field, choose Page Manager.
In the Job Parameters list, click New.
Click Parameters in the Server Tasks list, and then enter the appropriate parameters.
For a list of parameters, see Parameters of the Page Manager Server Component.
Parameters of the Page Manager Server Component
The most important parameters are Modem Port, Dial Prefix, Long Distance Prefix, and Local Area Code. You can change the values for these parameters to match the values that your environment requires.
| Parameter | Description | Usage |
|---|---|---|
Modem Port |
The Component Object Model (COM) port where the modem is attached. The default value is COM1. |
Valid values are COM1, COM2, and so on. |
Dial Prefix |
A number or sequence of numbers that Siebel CRM dials to get an outside line. The default value is 9. |
If you do not use a dial-out prefix, then insert a comma (","). If dialing 9 for an outside line is not required, and if you use srvrmgr.exe from the command line, then defining a comma for this parameter returns an error. If you include a hyphen or another character that Siebel CRM cannot use, then it does not return an error. The following example includes a dial prefix: SRVRMGR.EXE /g NT01022 /e SBLPRD_ENT502 / s SBLPRD_APP502 /u ***** /p ***** /c "START TASK FOR COMPONENT PageMgr WITH DialPrefix = '-'" |
Long Distance Prefix |
The long-distance prefix. The default value is 1. |
Siebel CRM prefixes this value to the front of a long-distance phone number. If your location does not require a long-distance prefix, then set this parameter to equal an empty string. |
Local Area Code |
The area code of your location. The default value is empty. |
If the beginning digits of a phone number are equal to this code, then Siebel CRM removes them before it dials the phone number and does not add the long-distance prefix. |
Delay1 |
The number of seconds to wait between dialing a phone number and simulating key presses for the first set of numbers. The default value is 12. |
Applies only to numeric paging. Siebel CRM ignores this parameter for alphanumeric paging. |
Delay2 |
The number of seconds to wait between simulating key presses for the first and second set of numbers. The default value is 4. |
Applies only to numeric paging. Siebel CRM ignores this parameter in the following situations:
|
Modem Reset String |
The modem command that Siebel CRM uses to reset the modem. The default value is ATZ. |
To determine the correct command, see your modem documentation. |
Modem Init String |
The modem command that Siebel CRM uses to initialize the modem. The default value is AT&FQ0V1. |
To determine the correct command, see your modem documentation. For example, some modems require a numeric value after &F. |
Modem Dial String |
The modem command that Siebel CRM uses to dial the modem. The default value is ATDT. |
These parameters are rarely changed. |
Modem Hangup String |
The modem command that Siebel CRM uses to hang up the modem. The default value is ATH. |
|
Modem Restore String |
The modem command that Siebel CRM uses to restore the power-up settings of the modem. The default value is AT&F. |
|
Request Key |
When you have more than one Page Manager, the request key serves as the ID for each Page Manager. You can then specify this key for the Workflow action in the Workflow Action Argument view. The request key can be any string. |
Troubleshooting Email Manager and Page Manager
When troubleshooting Email Manager and Page Manager, note the following:
If Email Manager cannot log on to the mail server that is compliant with SMTP or POP3, then it stops processing and logs an error message in the trace files.
If Email Manager can log on but encounters a problem sending an email, then it logs an error message and continues to the next request.
If the modem is not available, then Page Manager stops processing and Siebel CRM accumulates requests in the Requests table. After you fix the processing problems, you must restart the Siebel Server. The Siebel Server continues to process messages from the point where it was interrupted.
If Page Manager can interface with the modem but encounters a problem with a page send, then it logs an error and continues to the next request.
If a workflow policy runs email and paging actions, then it inserts email requests and paging requests in the Siebel database. It inserts these requests as records in the S_APSRVR_REQ table, which the Email Manager and Page Manager then process.
A new request includes a QUEUED status. When the Email Manager or Page Manager begins to process a request it sets the status to ACTIVE. When it finishes processing the request it sets the status to one of the following values:
SUCCEEDED if it processes the request successfully
FAILED if an error occurs
To send emails, Siebel Server uses the UNIX Mail command.
Making Sure the Siebel Server Can Send an Email to a Valid Recipient
This topic describes how to make sure the Siebel Server can send an email to a valid recipient.
To make sure the Siebel Server can send an email to a valid recipient
From the UNIX command prompt, enter the following command:
>mail recipient_email_address
where:
recipient_email_address is a valid email address
Enter a message that ends with a period on the last line.
For example:
This period indicates the end of the message.
Press enter.
If Siebel CRM writes an email to the S_APSRVR_REQ table but does not send it, and if the Email Manager trace file includes a SUCCEEDED status for this email, then make sure the following Outlook options are set on the email server:
Send messages immediately
Check for new messages every x minutes
To make sure Siebel CRM sends an email successfully, you must configure each of these options in Outlook.
Running a Workflow Policy with the Workflow Action Agent
If Siebel CRM runs an action, then the Workflow Action Agent sends a request to the Email Manager and Page Manager. You must define a component for each Workflow Action Agent server task. The Workflow Action Agent does the following:
Processes requests that Siebel CRM logs in the S_ESCL_ACTN_REQ (escalation action request) table for a single group. For more information, see Tables That Workflow Monitor Agent Uses.
Calls actions that are linked with the workflow policy that Siebel CRM processes for Siebel Workflow.
Logs email and page actions in the S_APPSRVR_REQ table so that Email Manager and Page Manager can run them.
Purges requests from the S_ESCL_ACTN_REQ table after Siebel CRM finishes processing.
If the Use Action Agent parameter is set to TRUE in the Monitor Agent process, then you must do the work described in Starting the Workflow Action Agent.
Starting the Workflow Action Agent
You can start the Workflow Action Agent in the same way that you start the Workflow Monitor Agent. For more information, see Creating a New Workflow Monitor Agent Server Component.
If you start the Workflow Action Agent, then it is recommended that you use the following guidelines:
A Workflow Action Agent exists for each Workflow Monitor Agent. You must start only one Workflow Action Agent for each Workflow Monitor Agent.
If your environment uses email consolidation, and if you set the Use Action Agent parameter to TRUE on the Workflow Monitor Agent, then you must start Workflow Action Agent separately.
For more information about starting Workflow Action Agent, see Siebel System Administration Guide.
Shutting Down the Workflow Action Agent
You shut down the Workflow Action Agent in the same way that you shut down the Workflow Monitor Agent. For more information, see Creating a New Workflow Monitor Agent Server Component.
If you restart a workflow policy process, then a Workflow Action Agent process immediately begins tracking relevant activities that occurred since it was shut down.
Using Workflow Action Agent for Batch Policies
You can run Workflow Action Agent separately with batch policies. Workflow Action Agent does not typically improve how Siebel CRM runs a batch policy, but if the action persists for a long time or is intensive, then the Workflow Action Agent might improve this processing.
To use workflow action agent for batch policies
Start Workflow Monitor Agent with the following parameters:
Group Name
Processes the batch policies is TRUE
Use Action Agent is TRUE
Start Workflow Action Agent with the Group Name parameter.
The Workflow Monitor Agent continues processing and enters the qualified rows in the S_ESCL_ACTN_REQ table. The Workflow Action Agent runs actions for rows in the S_ESCL_ACTN_REQ table, and then deletes rows from the S_ESCL_ACTN_REQ table. For more information, see Tables That Workflow Monitor Agent Uses.
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 Name | Description |
|---|---|
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.
Field Description 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.
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 developer workspace, then you must deliver the workspace. 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
Deliver the modifications done to a workflow policy object, column or program.
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
| Parameter Name | Display Name | Description | Default Value |
|---|---|---|---|
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:
|
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:
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:
|
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
| 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.
Configuring a Workflow Policy to Run in Batch Mode
Running a workflow policy in batch mode allows you to evaluate more data in the Siebel database and not only the records that call a workflow policy. This configuration is useful if you create a new workflow policy that Siebel CRM must apply to historical data, and for enforcing a workflow policy that includes a date condition.
To configure a workflow policy to run in batch mode
In the Siebel client, navigate to the Administration-Business Process screen, and then the Policy Groups view.
Create a new Policy Group.
In the Name and Comments fields, enter a descriptive name and comment.
Navigate to the Administration-Business Process screen, and then the Policies view.
In the Policies List, query the Name field for the workflow policy you must run in batch mode.
In the Policies List, make sure the Batch Mode field contains a check mark.
If you start workflow monitor in batch mode, then it determines if workflow policies exist with the Batch Mode check box marked. To identify the records that meet the workflow policy conditions, each policy causes Siebel CRM to send an SQL statement. It then processes these records and performs the appropriate actions.
In the Policy Group field, associate the workflow policy with the workflow group you created in step 2.
Optional. Consolidate email messages:
Add a condition in the Conditions list and a corresponding action in the Actions list.
Consolidate email messages. In the Actions list, click the Consolidate field.
For more information, see Consolidating Email Messages.
When you start the Workflow Monitor and Workflow Action server components, use the group name you created in step 2 and set the Processes the Batch Policies parameter to TRUE.
For more information, see Setting the Parameters of the Workflow Monitor Agent.
If you create a batch workflow policy, then you must use an IS ADDED, IS UPDATED, or IS DELETED comparison operator in conjunction with regular workflow policy conditions. These comparison operators are special conditions that Siebel CRM uses for Dynamic mode when it triggers rows to look up regular conditions.
Consolidating Email Messages
If you configure Siebel CRM to consolidate messages, then it sends one email to the recipient that includes information about multiple actions rather than sending information about multiple actions in multiple emails. For example, you can define a workflow policy that sends an email to a sales director each time a sales representative sends a quote that includes a discount over 30%. If 20 sales representatives send quotes that include the 30% discount, and if the Batch Mode field is:
Checked. The sales director receives one email that lists the 20 quotes.
Not checked. The sales director receives 20 email messages.
To consolidate email messages
In the Siebel client, navigate to the Administration-Business Process screen, and then the Actions view.
Make sure the Consolidate field in the Actions list contains a check mark.
Configuring Batch Mode to Make Sure Siebel CRM Calls a Workflow Policy Correctly
You can configure batch mode to make sure Siebel CRM calls a workflow policy correctly.
To configure batch mode to make sure Siebel CRM calls a workflow policy correctly
Make sure the Batch Mode field is checked for the workflow policy.
Set the Batch Mode parameter to TRUE for the Workflow Monitor Agent.
Example of Configuring Batch Mode to Make Sure Siebel CRM Calls a Workflow Policy Correctly
| Field | Value |
|---|---|
Workflow Policy Name |
Account Active |
Workflow Object |
Account |
Group |
Test |
In this example, to monitor a field, Siebel CRM starts a workflow policy that references a business object when the following situations occur:
Workflow Condition, Account Status is Active.
Workflow Action, Action: Send Email to Employee.
Remove and create database triggers, and then start a workflow monitor server task for the Test workflow group.
Note the following:
If a user adds a new account that meets these requirements, then Siebel CRM calls the workflow policy.
If a user updates an existing account in such a way that these requirements are met, then Siebel CRM calls the workflow policy.
If an account existed in the Siebel database before you created the workflow policy, and if the account meets the requirements that you define for this workflow policy, then this workflow policy does not start a workflow process for this account.
If Siebel CRM creates database triggers for this workflow policy, then the Workflow Monitor Agent evaluates a record only if the user updates it or if the user creates a new record. Old records are not affected.
To evaluate an account record that existed before you created the workflow policy, make sure the Batch Mode field is checked for the workflow policy, and that the Workflow Monitor Agent runs with Batch Mode set to TRUE.
Moving a Workflow Policy to a Different Group
To reply to changes in the business environment or to your configuration, it might be necessary to move a workflow policy to a different workflow group. Siebel CRM must finish requests that are associated with the workflow policy before you can move a workflow policy from one group to another group. If you move a workflow policy to a different workflow group while a request is pending, then Workflow Monitor Agent fails with a Rule Not Found error. In this situation, you must move the workflow policy back to the original group and wait for the request to finish.
If you move a workflow policy to a different workflow group, then you must also update database triggers. These triggers contain the RULE_ID and GROUP_ID for the workflow policy. If you do not update them, then rows in the S_ESCL_REQ table reference the original RULE_ID and GROUP_ID. For more information, see Tables That Workflow Monitor Agent Uses.
To move a workflow policy to a different group
To drop database triggers, run a Generate Triggers server task using the following parameters:
EXEC=TRUE Remove=TRUE
Dropping database triggers makes sure Siebel CRM does not insert any more rows for workflow policies in the group you must change. To avoid starting more database triggers, it is recommended that you make these changes only if no users or only a minimal number of users are currently using Siebel CRM. For more information, see Configuring Database Triggers.
If a Workflow Monitor Agent server task is already running, then allow the Siebel Server task to finish.
This step makes sure the Siebel Server task processes the remaining rows in the S_ESCL_REQ table for the workflow policy group.
To make sure no more rows occur for GROUP_ID, query the S_ESCL_REQ table for the GROUP_ID.
If no server task for the monitor agent is running for the group, then start a server task for the group with the proper group name.
Wait for Siebel CRM to finish processing the remaining rows in the S_ESCL_REQ table for the group.
Stop the Siebel Server task of the Workflow Monitor Agent for the group.
To reassign the workflow policy to the group, change the field of the group name for the workflow policy to the new group name.
Generate database triggers again, using the following parameters:
EXEC=TRUE Remove=FALSE
Restart the Workflow Monitor Agent for the old group.
Start a new Workflow Monitor Agent for the new group.
Restart the Workflow Monitor Agent for the old group.
Start a new Workflow Monitor Agent for the new group.
Converting a Workflow Policy to a Workflow Process
It is recommended that you keep a workflow policy simple and place most business logic in a workflow process. You can convert a workflow policy to a workflow process.
If you convert a workflow policy to a workflow process, then it is recommended that you use the guidelines the following table describes.
| Configuration Used in a Workflow Policy | Configuration Used in a Workflow Process |
|---|---|
A specialized operator, such as IS UPDATED or IS ADDED. |
A run-time event. |
A standard operator, such as = or <>. |
A branch or decision step. |
A workflow policy program performs an operation at the Siebel database layer. |
A Siebel operation step at the object layer uses logic that modifies data at the data layer. A workflow process cannot call a workflow policy program, but a Siebel operation step can perform an operation in the data layer. |
Not applicable |
A workflow process uses the communication outbound manager to send email. It can use a recipient group and the exact email address. |
Configuring a Workflow Policy to Reference Multiple Tables
A workflow policy references a database trigger and the workflow policy can run on a database record only after Siebel CRM commits the record. If a workflow policy references multiple database tables, then it goes into effect only after Siebel CRM commits the records on these tables.
For example, Siebel CRM stores opportunity revenue in the S_OPTY_POSTN table and lead quality in the S_OPTY table. A workflow policy that applies each of the following workflow policy conditions goes into effect only after Siebel CRM commits the records on each table:
Opportunity Revenue > 10M
Lead Quality is High
To defined multiple business components for the same database table, you can use a search specification. If you configure a workflow policy component to monitor a business component, then make sure you configure Siebel CRM to reference fields in the search specification as workflow policy columns. To enforce the required behavior, you can then use the workflow policy column in the workflow policy conditions.
Expiring a Workflow Policy
When you expire a workflow policy, you can remove rows that belong to the expired or workflow policy in the S_ESCL_REQ table, which is preferable to deleting the workflow policy.
To expire a workflow policy
Make a backup copy of the Siebel database or the effected tables.
If necessary, you can use this backup later to restore the tables to their state that existed before you deleted rows.
Use SQL to manually delete the rows that reference expired or deleted workflow policies. Delete these workflow policies according to RULE_ID.
For example:
delete from table name where RULE_ID = 'rule_id'
Siebel CRM does not support direct delete or update statements on the Siebel database. Also, the following tables are the only tables that do not contain dependencies. Make sure you perform this procedure in accordance with Siebel Support guidelines:
S_ESCL_REQ
S_ESCL_ACTN_REQ
S_ESCL_STATE
Expire the workflow policy:
Log in to the Siebel client, and then navigate to Administration-Business process screen.
Locate the workflow policy you must expire in the Policies view.
Enter a date and time in the Expiration field that has already occurred.
To delete database triggers that reference expired workflow policies, run the Generate Triggers server task with the following parameters:
Drop Triggers:
EXEC = True Remove = True
Generate Triggers:
EXEC = True Remove = False
If some workflow policies are expired, and if these policies did not drop and recreate database triggers, then the database triggers for these policies can still cause Siebel CRM to insert records in the tables for Siebel Workflow. Dropping these database triggers prevents Siebel CRM from creating rows in the S_ESCL_REQ table that are related to expired policies.
If necessary, recreate database triggers.
For more information, see Configuring Database Triggers.
If the errors continue, then get help from Oracle.
Include a description of the steps you performed to resolve the error, along with a copy of the Workflow Monitor trace files with the following traces set:
Error Flags = 2 SQL Trace Flags = 2
For more information, see How to Get Help with an Error of a Workflow Process.
Resolving a Problem That Fails to Load Parent Rows
If Siebel CRM displays a Failed to Load Parent Rows error message, then it might be due to the presence of rows in the S_ESCL_REQ, S_ESCL_STATE table and the S_ESCL_ACTN_REQ table that reference an expired workflow policy. This topic describes how to use SQL queries to determine if rows exist in these tables that reference a policy that no longer exists in the S_ESCL_RULE table.
To resolve a problem that fails to load parent rows
Look for the following error message in the WorkMon_file_number.log trace file:
[DBG33] 2000-01-24 08:49:30 Message: Rule not found [DBG33] 2000-01-24 08:49:30 Message: Failed to load parent rows
Siebel CRM logs this error message if Workflow Monitor agent attempts to process records from the S_ESCL_REQ, S_ESCL_STATE table or the S_ESCL_ACTN_REQ table but the workflow policy that it is trying to review is expired or deleted.
To determine if records exist that reference an expired workflow policy, run the following query:
select row_id, name, expire_dt from s_escl_rule where expire_dt is not null and expire_dt <= getdate()
Sysdate is an Oracle date time function. The corresponding function for SQL Server is getdate.
Note the ROW_ID for the expired workflow policy identified in step 2.
To determine the number of records that exist in the S_ESCL_REQ table that reference an expired workflow policy, run the following query:
select * from s_escl_req where rule_id in (select row_id from s_escl_rule where expire_dt is not null and expire_dt <= getdate())
Repeat the last step for the S_ESCL_STATE and S_ESCL_ACTN_REQ tables.
If records exist in the S_ESCL_REQ, S_ESCL_STATE table, or the S_ESCL_ACTN_REQ table that reference an expired workflow policy, then log in to the Siebel client and start the Workflow Monitor Agent with Ignore Errors set to TRUE.
Workflow Monitor Agent can bypass the error and clean the S_ESCL_REQ table.
Caution: To clean up the workflow tables, you can temporarily set Ignore Errors to True. It is strongly recommended that you do not permanently set Ignore Errors to True.Stop the Siebel Server task.
Restart the Siebel Server task with Ignore Errors set to FALSE.
This step makes sure you do not overlook other types of errors.
If the errors continue, then delete rows by RULE_ID, expire old workflow policies, and delete database triggers.
Deleting an Obsolete Workflow Policy
You delete an obsolete workflow policy for the following reasons:
To avoid the ESC-00054 error when you start Workflow Monitor.
To avoid the unnecessary use of storage space. Normally, Workflow Monitor does not process rows that are associated with an obsolete workflow policy. The rows remain unused in the S_ESCL_REQ table.
Database triggers are still in effect when you expire or delete a workflow policy and shut down the Workflow Monitor. Database triggers that are related to an expired or deleted policy continue to work until you delete them from the Siebel database. Siebel CRM might continue to trigger rows in the S_ESCL_REQ table between the time you expire a workflow policy and the time you finish dropping and redefining database triggers.
You might encounter the ESC-00054 error when you start the Workflow Monitor because Workflow Monitor Agent finds workflow policies in the S_ESCL_REQ table that are not active or are not present. The workflow policies that Siebel CRM stores in the S_ESCL_RULE table must remain in the S_ESCL_REQ table and Siebel CRM must not process them.
If Use Action Agent is set to FALSE for the Workflow Monitor, then the Workflow Monitor Agent runs for the Action Agent, bypasses the S_ESCL_ACTN_REQ table, and uses only the S_ESCL_REQ table. If rows in the S_ESCL_REQ table exist for a workflow policy that is expired or deleted, then you must delete them before you start the Workflow Monitor. For more information, see Expiring a Workflow Policy.
For more information, see Tables That Workflow Monitor Agent Uses.
Locating Workflow Policies That Are Deleted or Expired
The examples in this topic can help you determine if rows in the S_ESCL_REQ table exist that are related to a deleted or expired workflow policy. For more information, see Tables That Workflow Monitor Agent Uses.
Locating Deleted Workflow Policies
You can enter a query that locates deleted workflow policies.
To locate deleted workflow policies
Run the following query:
select RULE_ID, count(RULE_ID) from S_ESCL_REQ a where not exists (select row_id from S_ESCL_RULE b where a.RULE_ID = b.ROW_ID) group by RULE_ID
Locating Expired Workflow Policies
You can enter a query that locates expired workflow policies.
To locate expired workflow policies
Run the following query:
select a.RULE_ID, b.NAME, count (a.RULE_ID), b.EXPIRE_DT, b.SUB_TYPE_CD from S_ESCL_REQ a, S_ESCL_RULE b where a.RULE_ID = b.ROW_ID and b.EXPIRE_DT < sysdate group by a.RULE_ID, b.NAME, b.EXPIRE_DT, b.SUB_TYPE_CD
where:
sysdate is the Oracle current date and time function.
Determine if the workflow policies unintentionally expired.
An example of a workflow policy that unintentionally expires is someone forgetting to extend the dates but nobody changed the database triggers since the policy expired.
If you determine a workflow policy unintentionally expired, and if Siebel CRM must process the rows, then do the following:
If the Workflow Monitor is running, and if it is not necessary for you to shut it down, then reverse the expiration of the workflow policy. To do this, enter a new date and time in the Expiration Date field for policy. Make sure this date and time is greater than the current date and time.
The workflow policy goes into effect after 10 minutes. This delay occurs because the default for the Reload Policy parameter of Workflow Monitor is 600 seconds.
If you require the workflow policy to go into effect immediately, then shut down Workflow Monitor if it is running, reverse expiration of the policy, and then start Workflow Monitor.
You can also do this work with a workflow policy that includes a duration.
Monitoring, Testing, Troubleshooting, and Migrating a Workflow Policy
This topic describes testing, troubleshooting, and migrating a workflow policy. It includes the following topics:
Tracing a Workflow Policy
When Siebel CRM starts a Workflow Policies server process, it creates a trace file for the following Siebel Server tasks:
Generate Triggers
Page Manager
Email Manager
Workflow Monitor Agent
Workflow Action Agent
You can view trace files for workflow policies and Siebel Server tasks and examine them for error messages and other information.
To view trace files for workflow policies and Siebel Server tasks
In the Siebel client, navigate to the Administration-Server Management screen, Tasks, then the Log view.
The Tasks list displays the status of the Siebel Server tasks as running or started.
To view trace files in the Siebel Server
To view trace files in the Siebel client, navigate to the Administration-Server Management screen, Tasks, and then the Log view.
The Tasks list displays the status of the Siebel Server tasks as running or started.
To view trace files on the Siebel Server, do one of the following:
Use Windows Explorer to navigate to the following directory, and then choose the name for the Siebel Server. You can examine a file that lists the trace files for each server process:
Siebel Server\log
Double-click the Trace File icon to access the trace file. You can view the trace file for application server tasks.
For more information about using trace files, see Siebel System Administration Guide.
Log Levels for Tracing and Events for Workflow Policies
The following table describes the events that workflow policies use for logging. Setting a trace level over the default parameter affects performance. It is recommended that you reset the trace level to the default parameter after you finish troubleshooting.
Table Log Levels for Tracing and Events for Workflow Policies
| Event | Level | Description |
|---|---|---|
SqlParseAndExecute |
4 |
Traces SQL statements and execution times. |
Object Assignment |
3 |
Traces Workflow Monitor Agent while it performs Dynamic Assignment. Used in conjunction with Rules Evaluation. |
Rules Evaluation |
4 |
Traces Workflow Monitor Agent while it performs Dynamic Assignment. Used in conjunction with Object Assignment. |
Task Configuration |
4 |
Parameter configuration of the Siebel Server task. |
Using Charts and Reports for Workflow Policies
You can use charts to analyze how frequently a workflow policy condition is met and the total number of policy instances that occur during a particular time period. Reports also summarize workflow policy and workflow log information.
The Policy Frequency Analysis view displays information about the number of times a workflow policy runs. The Policy Trend Analysis view displays information about workflow policy trends.
To use charts and reports for workflow policies
Display frequency and trend information about a workflow policy:
In the Siebel client, navigate to the Administration-Business Process screen, and then the Policy Frequency Analysis view.
Examine the view, using values described in the following table.
List or View Description Monitor Log
Lists the workflow policies.
Workflow Policy Frequency Analysis
Displays a chart that illustrates how frequently a workflow policy runs.
To toggle between the Workflow Policy Frequency Analysis view and the Workflow Policy Trend Analysis view, you can use the toggle feature on the chart view.
Workflow Policy Trend Analysis
Displays the total number of workflow policy conditions that are met over a particular time period.
Display a report for a workflow policy:
In the Siebel client, navigate to the Administration-Business Process screen, and then the Policies view.
In the menu bar, click the Reports icon, and then choose Workflow Policy.
Siebel CRM opens a separate Siebel Report Viewer window that displays summary information for the workflow policy.
You can also display a similar report for the Log views.
Using the Workflow Policy Log to Monitor a Workflow Policy
The Workflow Policy Log view displays a log of the records that meet a workflow policy condition that the Workflow Monitor Agent process tracks.
To use the workflow policy log to monitor a workflow policy
In the Siebel client, navigate to the Administration-Business Process screen, and then the Policy Frequency Analysis view.
Query the Policy field for the workflow policy you must monitor.
Examine the log using values from the following table.
Field Description Policy
The name of the workflow policy.
Workflow Object
The name of the workflow policy object.
Object Identifier
The Id of the workflow policy object that meets the workflow policy condition.
Object Values
Identifying information for the row that met the workflow policy condition.
Event
The date and time that the workflow policy condition is met.
Testing a Workflow Policy
Testing a workflow policy before you implement it in a production environment increases the likelihood that the recipient of an action receives accurate and useful information, and that the overall results meet the business requirements for the workflow process. It is critical that you thoroughly test your workflow policy and fix problems before you implement the workflow policy in a production environment.
To test a workflow policy
Develop a testing and migration strategy for introducing changes in the production environment.
For more information, see Creating a Plan for the Test and Migration Strategy.
Make sure you installed the workflow policy components on the Siebel Server.
For more information, see Siebel System Administration Guide.
Make sure the Siebel Server processes that your workflow policy requires for email and pager are running.
Make sure the Workflow Agent processes are running.
Make sure each workflow policy, workflow policy condition, and workflow policy action runs as expected:
To test your workflow policy, enter data that meets the workflow policy conditions.
Make sure the policies, conditions, and actions are correctly defined.
Make sure the policies, conditions, and actions accurately define the transactions.
Make sure the workflow policy actions perform as expected and occurs when expected:
Make sure Siebel CRM creates the required database triggers.
Make sure the action interval and sleep times are correctly defined.
Make sure the proper action runs. For example, you can determine if the email arrives or that the pager notification activates. To monitor progress of the Workflow Agent, you can use the Workflow Policies Log view. For more information, see Using the Workflow Policy Log to Monitor a Workflow Policy.
After you verify that the workflow policy runs as expected, you can migrate it to your production environment.
For more information, see Migrating Workflow Policies to the Production Environment.
Fixing a Workflow Policy That Does Not Trigger
This topic describes how to troubleshoot a workflow policy that does not trigger.
To fix a workflow policy that does not trigger
Make sure your test record meets the workflow policy conditions.
Make sure the Siebel client configuration file references the correct Siebel Server.
If the Siebel client configuration file does not reference the correct Siebel Server, then an error that is similar to the following might occur:
ESC-00053 Error loading rule definitions
Examine the date and time that Siebel CRM activated the workflow policy.
Examine the monitor task:
Determine if the monitor is awake and running on the correct group.
Search the Task Information log for the ROW_ID of your test record:
If ROW_ID does not exist, then run GENERATE TRIGGERS.
Update your test record.
Examine the Action Agent task:
Determine if the Action Agent is awake and running on the correct workflow policy group.
Search the Task Information log for the ROW_ID of the test record.
Make sure Siebel CRM creates the database triggers.
Tracing a Workflow Policy
Siebel CRM uses the General Events event to log a workflow policy. To view informational messages, you can set the log level to 3. To view debugging information, set the log level to 4. For more information, see Tracing a Workflow Policy.
Migrating Workflow Policies to the Production Environment
To migrate workflow policies to a production environment, you use a procedure that is similar to the procedure you use to migrate policies to a test environment. To help prevent invalid database triggers in the production environment, you apply them in the test environment before you apply them in the production environment.
To migrate workflow policies to the production environment
Back up your production environment database.
Migrate the test repository environment to the production repository environment.
For more information, see the upgrade guide for the operating system you are using.
Redefine the following items that you defined in the test environment in the production environment:
Workflow policy action types
Workflow policies
Workflow policy groups
When you redefine the object definitions in the production environment, make sure you redefine them exactly as you defined them in the test environment. It is not necessary to redefine information that you defined through Siebel Tools.
In the Siebel client, navigate to the Administration-Server Management screen, and then the Jobs view.
In the Jobs list, click New.
In the Component/Job field, choose Generate Triggers.
This step creates a new line entry but does not start the Siebel Server task.
In the Job Parameters list, click New to modify parameter settings.
For a description of the parameters that are specific to the Generate Triggers server component, see Administering Database Triggers on the Workflow Policy Server. For a description of generic and enterprise parameters, see Siebel System Administration Guide.
Choose Submit Query.
Use trace files to monitor Siebel CRM, as required.
For more information, see Tracing a Workflow Policy and Siebel System Administration Guide.
Setting the Component Parameters before Running Workflow Policies
When the workflow changes are delivered to the Integration branch, for running the workflow policy, set the WorkspaceBranchName to Integration Branch and run the following commands.
Component WfProcMgr
Component GenTrig
Component WorkMon
For example, set the component parameters as following:
Component WfProcMgr
Parameter WorkspaceBranchName="Name of the integration Branch"
Component GenTrig
Start task for component GenTrig server <serverName> with exec=true
privuserPass=DB Password
privuser=DB Instance
username=SADMIN
password=MSSQL
Component WorkMon
Start task for component WorkMon with SleepTime=10
GroupName=”Name of the Group Created”
username=SADMIN
password=MSSQL