Monitoring Workflow Policies

You need to monitor Workflow Policies regularly to check that all events are handled correctly and that the Siebel Server uses its resources optimally. Purging your log files periodically prevents them from becoming too large. Workflow Policies use the General Events event for logging. To see informational messages, set the log level to 3. To see debugging information, set the log level to 4.

You can monitor Workflow Policies using the following views, log files, and tables:

• Policy Frequency Analysis view. For details, see "Using the Policy Frequency Analysis View".

• Workflow Agent trace files. For details, see "Using Workflow Agent Trace Files".

• Workflow Policies tables. For details, see "Monitoring Workflow Policies Tables".

Using the Policy Frequency Analysis View

This topic is part of "Monitoring Workflow Policies".

The Policy Frequency Analysis view provides a list of all executed policies. The Policy Frequency Analysis view is available to analyze how frequently policies are executed over time.

This view displays a log of all of the policies executed, as evidenced by a Workflow Monitor Agent process. The policy maker can monitor Workflow Agent process activity to determine whether the current policies are adequate, new policies need to be created, or policies need to be refined.

The Policy Frequency Analysis view lets you view Policy Log data in a graphical format. The log information is generated by Siebel Server components for Workflow Policies. You access the Policy Frequency Analysis view from the Siebel client by navigating to Policy Frequency Analysis view in the Administration - Business Process screen.

The Policy Frequency Analysis view contains the following fields:

• Policy. The name of the policy that was executed.

• Workflow Object. The name of the assigned workflow policy object.

• Object Identifier. The ID of the workflow policy object for which the policy was executed.

• Object Values. Identifying information for the row that executed the policy.

• Event. The date and time of the policy execution event.

Using Workflow Agent Trace Files

This topic is part of "Monitoring Workflow Policies".

Workflow agent trace files include the following:

• Workflow Monitor Agent trace file. Workflow Monitor Agent provides detailed information about its processing in its trace file.

• Workflow Action Agent trace file. Workflow Action Agent provides detailed information about its processing in its trace file.

  Setting tracing on the Workflow Action Agent task is required only when the parameter Use Action Agent for Workflow Monitor Agent is set to TRUE. In this case, Workflow Action Agent must be started manually. (It also must be started manually when you use email consolidation.)

  Use Action Agent is FALSE by default: Workflow Action Agent is started automatically by Workflow Monitor Agent.

• Email Manager and Page Manager trace files.

  • Run Email Manager and Page Manager components with Trace Flag set to 1 for detailed reporting on email activity.

  • Query S_APSRVR_REQ for status information on email and page requests that were logged by Workflow Action Agent.

Monitoring Workflow Policies Tables

This topic is part of "Monitoring Workflow Policies".

Workflow Policies use three database tables for processing and tracking requests:

• S_ESCL_REQ

• S_ESCL_STATE

• S_ESCL_ACTN_REQ

Monitor these tables to verify that policies are being processed correctly.

When a trigger fires against a Workflow Policy condition, a record is inserted in the escalation request table, S_ESCL_REQ. Records in this table identify rows in the database that could trigger a Workflow Policy to take action. After the workflow Monitor Agent processes a request, it removes the row from this table.

The S_ESCL_STATE time-based table identifies all of the rows that have been executed (all conditions are true) and are waiting for the time duration element to expire.

The S_ESCL_ACTN_REQ table identifies all of the rows that are awaiting action execution. These rows have violated the policy; and the time duration element, if any, has expired.

If one of these tables (S_ESCL_REQ, S_ESCL_STATE, and S_ESCL_ACTN_REQ) becomes very large, then this could indicate that the number of policies being monitored is too large, and new Workflow Policies processes need to be created to share the load and improve performance.

If rows are being monitored, but are not being removed from a table after the time interval is met, then this could indicate that a policy was deactivated without removing the database triggers. The triggers are continuing to send data that is not being acted on by a Workflow Policies process. These tables will become very large if you do not restart Generate Triggers.

If you expire or delete any active Workflow Policies, confirm that no outstanding records remain in the S_ESCL_REQ, S_ESCL_STATE, or S_ESCL_ACTN_REQ tables.

Maintain the S_ESCL_REQ, S_ESCL_STATE, and S_ESCL_ACTN_REQ tables by adjusting parameters related to storage, access, and caching. See database documentation for additional information about properly adjusting such parameters. Also, make sure that the database administrator (DBA) is aware of these key tables.