Bookshelf Home | Contents | Index | PDF |
Siebel Business Process Framework: Workflow Guide > Administering Workflow Policies > About Workflow Policy Administration > Administering Triggers on the Workflow Policy ServerThis topic describes how to administer triggers on the workflow policy server. It includes the following topics:
Creating Database TriggersThe Generate Trigger (GenTrig) component on the Siebel Server allows you to create database triggers. Workflow Policies uses database triggers to identify which records match policy conditions. Run Generate Triggers when you:
To run Generate Triggers, you must have installed the Siebel Server, and the Siebel client you are using must be configured to access the Siebel Server Administration screens. For more information on installing Server Manager, see the installation guide for the operating system you are using. CAUTION: If you have incorrectly defined a policy condition, running Generate Triggers can result in invalid triggers. An invalid trigger can prevent execution of normal user transactions. For this reason, thoroughly test your policies in your test environment before you migrate them to your production system. Description of Generate Triggers ExecutionTable 68 describes how generating triggers works, depending on how the EXEC parameter is set.
The default setting for EXEC is FALSE. You can run the Generate Triggers component from the Server Manager graphical user interface or command-line mode. Both the GUI and the command-line use the same parameters. The triggers are only there to create indicators for the Workflow engine to check the policies' conditions. Example of GenTrig Behavior for a Workflow Policy With Multiple ConditionsWhen two or more conditions are used in a workflow policy, Generate Triggers displays the OR logic instead of the AND logic. Table 69 describes example conditions to use to create a workflow policy based on the Account object. Multiple triggers created for multiple conditions of one policy is expected behavior. This separates the functionality of GenTrig and WorkMon. GenTrig simply monitors database record changes and inserts records in Workflow Policy-specific tables. WorkMon evaluates violations, checks to see if the conditions associated with the rule of the violation are met, and executes the actions associated with a policy. You cannot use AND between triggers generated for multiple conditions of a policy, because GenTrig can monitor only database changes, and database changes that violate different conditions are not always concurrent. So using an AND condition causes GenTrig to miss many violations. For example, assume a policy has the following conditions: Two triggers are generated. One trigger monitors an SR being created or updated, and checks if the area equals Network. The other trigger monitors an activity being created or updated, and checks whether the Priority equals 1-ASAP. But if you use AND triggers and a user creates an SR without an activity, the trigger is not violated since the activity does not exist. If later, a user adds an activity to the SR, there still is no trigger violation because the SR record does not change. This violation is be missed due to use of AND logic. If, however, you use OR for the triggers and have WorkMon evaluate the condition, even though there are multiple violations in the S_ESCL_REQ table, WorkMon only processes one request because the other requests are not evaluated to TRUE. About Database Triggers and Database AdministrationIt is important to keep your database administrators informed of active workflow database triggers, as a database Update or Insert event causes the database trigger to react, regardless of how the event is executed. For example, if you have workflow triggers on inserts to the S_SRV_REQ table, and the database administrator does a table export and import of these records, the triggers treat every record in the database as if it is a newly inserted record, which can result in inappropriate actions being taken on old records that were simply imported again. NOTE: In this release, the Generate Triggers task now requires the Privileged User Name and Password instead of Table Owner ID and Password. Running Generate TriggersTips you can consider when running Generate Triggers, especially if you are deleting a policy, include:
To Generate Triggers using the Siebel client
Component-Specific Parameters for Generate TriggersTable 70 describes component-specific parameters for Generate Triggers. Running the SQL Script FileOnce Generate Triggers has finished, run the SQL script file if the EXEC parameter is FALSE.
For example, the policy administrator, Bill Stevens, has finished creating policies in the test Siebel client and needs the database triggers set in the Siebel database for the new policies. Using the Generate Triggers component, he sets the file output name. This creates a file, TRIGGER.SQL, for the database administrator containing the triggers that must be modified or created in the test database for these policies. The database administrator then runs the following command in SQL*Plus to create the triggers in the Oracle database: The successful creation of each database trigger in the Oracle database is indicated on the screen. For information on the syntax required for other databases, see your database documentation. NOTE: On an MS SQL server database, execute the script trigger.sql as the database owner, dbo, login for the Siebel database. About Database Triggers and Remote UsersWhen a remote user synchronizes, the changes get incorporated into the database. For example, account information in the S_ORG_EXT table is updated on synchronization. If you run a workflow which creates database triggers that compare changes in the database against specific conditions, then the triggers fire and rows are written to the S_ESCL_REQ table if the changes are of interest to the workflow conditions during synchronization. About the S_ESCL_REQ TableWhen a trigger fires against a Workflow policy condition, a record is inserted in S_ESCL_REQ, the escalation request table. This table contains the rows in the database that can trigger a workflow policy to take action. After the workflow monitor agent processes a request, it removes the row from this table. Frequently, because of the way triggers are created, the logic defined on a workflow policy condition is not included on the trigger itself. Also, the conditions in the trigger file might not be indicative of the policies actually being violated. When running workflow monitor agent the records in the S_ESCL_REQ table causes workflow to evaluate the conditions for the related policy. So the triggers are only there to create indicators for the workflow engine to check the workflow policy conditions.
Remedies to Address Problems Involving the S_ESCL_REQ TableRemedies you can apply to avoid or fix problems in the S_ESCL_REQ table include:
|
Siebel Business Process Framework: Workflow Guide | Copyright © 2008, Oracle. All rights reserved. | |