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

Deleting an Obsolete Workflow Policy

Triggers are still in effect at the time you expire or delete policies and shut down Workflow Monitor, and triggers related to expired or deleted policies continue to work since they are attached to database tables until they are deleted from the database. So, between the time you expire policies and the time you finish dropping and recreating triggers, there can be rows triggered for the expired policies in the S_ESCL_REQ table.

You can get the error ESC-00054 while starting Workflow Monitor because WorkMon looks for the policies referenced in the S_ESCL_REQ table and finds policies that are inactive or not present. The policies are stored in the S_ESCL_RULE table. Those rows must remain in the S_ESCL_REQ table and must not be processed at all.

Given that Use Action Agent is set to FALSE for Workflow Monitor, WorkMon also acts for Action Agent, bypasses the S_ESCL_ACTN_REQ table, and uses only the S_ESCL_REQ table. If you have rows in the S_ESCL_REQ table for policies that are expired or deleted, then you must delete them before starting Workflow Monitor. Reasons for doing this include:

• To avoid the error ESC-00054 when starting Workflow Monitor.
• To avoid taking up unnecessary space. Normally, Workflow Monitor does not process the rows at all. The rows remain unused in the S_ESCL_REQ table.

You can delete the rows by RULE_ID, which is the unique identifier for a Workflow Policy. Back up the database prior to doing the delete.

Example Queries for Locating Deleted and Expired Policies

The following are queries that can help you determine whether you have rows in the S_ESCL_REQ table that are related to deleted or expired policies.

Query to Locate Deleted Policies

To locate deleted 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

Query to Locate Expired Policies

To locate expired policies run the following query, where sysdate is the Oracle current date-time function:

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

If you determine that the workflow policies have expired unintentionally and you need to process the rows, then the tasks you can perform include:

• If the Workflow Monitor is running and you do not need to shut it down, reverse the expiration of the policies by entering a date-time greater than the current date-time in the Expiration Date field for policies.
• After a period of 10 minutes, the policy takes effect. This is because the Reload Policy parameter of Workflow Monitor is set to 600 seconds as the default.
• If you need the policy to take effect immediately, then you can shut down Workflow Monitor, if it is running, reverse expiration of the policies, then start Workflow Monitor.

You can also take these actions with a policy that has a duration.

An example of policies expiring unintentionally is someone forgetting to extend the dates and nobody changed the triggers since the policies expired.