Siebel Business Process Framework: Workflow Guide > Administering Workflow Policies > About Workflow Policy Administration >

Expiring a Workflow Policy

When expiring a workflow policy you should remove records associated with the workflow policy in the S_ESCL_REQ table. This is preferable to deleting a workflow policy.

If you encounter a failed to load parent rows error message, it can be due to the presence of rows in the S_ESCL_REQ, S_ESCL_STATE and S_ESCL_ACTN_REQ tables that reference expired policies. The procedure in this topic allows you to determine, by using SQL queries, if there are rows in these tables that reference policies that no longer exist in S_ESCL_RULE.

To avoid workflow manager exiting with error, make sure there are no outstanding records in the S_ESCL_REQ, S_ESCL_ACTN_REQ or S_ESCL_STATE tables before expiring the policies.

CAUTION:  Setting Ignore Errors to True is primarily used to clean up the Workflow Tables. It is strongly discouraged to permanently set Ignore Errors to True.

To remove rows belonging to expired or deleted policies

1. Look for the following error message in WorkMon_xxx.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

     This error message indicates an error when Workflow Monitor agent attempts to process records from the S_ESCL_REQ, S_ESCL_STATE or S_ESCL_ACTN_REQ tables, and the policy that it is trying to review is expired or deleted. For more information about these tables, see About Workflow Monitor Agent.

2. Run the following query to determine if there are records that reference expired policies:

   select row_id, name, expire_dt

   from s_escl_rule

   where expire_dt is not null and expire_dt <= getdate()

   Note that sysdate is an Oracle date time function and the corresponding function for SQL Server is getdate().

3. Note the ROW_ID's for the expired policies exposed in Step 2.
4. Run the following query to determine the number of records in the S_ESCL_REQ table that reference expired policies:

   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())

5. Repeat Step 4 for the S_ESCL_STATE and S_ESCL_ACTN_REQ tables.
6. If there are records in the S_ESCL_REQ, S_ESCL_STATE, S_ESCL_ACTN_REQ tables that reference expired policies, in the Siebel client, start the Workflow Monitor Agent with Ignore Errors set to TRUE.

   Workflow Monitor Agent should be able to bypass the error and clean the S_ESCL_REQ table.

   Note the caution information provided at the beginning of this topic.

7. Stop the task.
8. Restart the task with Ignore Errors set to FALSE.

   This makes sure other types of errors are not missed.

If the error continues after completing this procedure, continue with delete rows by RULE_ID, expire old policies, and drop triggers.

To delete rows by RULE_ID, expire old policies, and drop triggers

1. Make a backup copy of the database or the effected tables.
2. Identify the RULE_IDs that belong to policies that no longer must be enforced by Workflow.
3. Use SQL to manually delete the rows that reference expired or deleted policies.

   Delete these policies by RULE_ID. For example:

   delete from [table name] where RULE_ID = 'rule_id'

   Note that the Siebel application does not support direct delete or update statements on the Siebel database. Also, note that S_ESCL_REQ, S_ESCL_ACTN_REQ, S_ESCL_STATE are the only tables that do not have dependencies. Make sure you perform this procedure in accordance with Siebel Support guidelines.

   Performing the backup in Step 1 makes sure you have a backup you can use to restore the tables to their state before rows were deleted, if necessary.

4. For policies that should not be active, expire them by putting an older date time in the Expiration Date/Time field for the policies.
5. To drop triggers that reference expired policies, run the generate trigger server task with the parameters listed, below.

   Drop Triggers:

   EXEC = True

   Remove = True

   Generate Triggers:

   EXEC = True

   Remove = False

   If some policies have expired and not dropped and regenerated triggers, the triggers for those policies can still be causing records to be inserted into the Workflow tables.

   Dropping these triggers should prevent rows related to those expired policies from being created in the S_ESCL_REQ table.

6. If necessary, regenerate triggers.

   For more information, see Running Generate Triggers.

7. If the errors persist, create a service request.

   Include a description of the steps you have taken to resolve the error, along with a copy of the Workflow Monitor trace files with the following trace flags set:

   Error Flags = 2

   SQL Trace Flags = 2

   For more information, see Getting Help With A Workflow Error.