Troubleshooting — Service level rules not executing

Diagnosis

Action

The Pega-ProCom agent monitors the time intervals associated with service level rules. Review the Data-Agent-Queue data instance named Pega-ProCom on each node, which contains an Enabled? check box.

Check the Enabled? box in the Agent-Wide Settings area. Save the Agent Schedule form to enable the agent. (The Master Agent normally starts the Pega-ProCom agent within 60 seconds.)

Diagnosis

Action

The standard activity named Assign-.ProcessServiceLevelEvents controls service level processing. It can be enabled or disabled though a check box on the Agent Schedule form.

Check the Enabled? box for this row. Save the Agent Schedule form. Restart the agent using the Agent Management menu on the System Management application.

Diagnosis

Action

Examine the Access Group field on the Data-Agent-Queue instance for the Pega-ProCom agent. Open this access group and confirm that it provides — directly or indirectly — access to the RuleSets and Versions that contain the service level rules.

Update an access group or the agent queue instance to ensure that the Pega-ProCom agent can execute all the service level rules in your application.

To make a RuleSet version available to every agent, add it to the Production RuleSets area of the PegaRULES:Agent access group; this access group is used by the Batch requestor type.

Diagnosis

Action

Some service level rules may be unavailable.

Open each service level, being careful to open the highest-numbered version that the Pega-ProCom agent can access. Examine the Service Level form; confirm that the Availability is set to Yes () or Final ().

Diagnosis

Action

Using the System Management application, you can determine the last time that the agent began processing.

If the agent failed, note the exact time and date. Examine the system log for a message with that time and date.

Diagnosis

Action

Although rarely used, a prconfig.xml file setting can disable all agent processing for a node.

Review the prconfig.xml file for the current node.

Diagnosis

Action

In some cases, escalation processing of service levels may occur properly but be difficult to detect.

Review each service level rule and identify the assignment or work object properties that are affected. Then review assignments and work objects that you believe were processed, to see whether their property values reflect escalation processing.

By default, Process Commander does not record escalation processing in work object history. Your service level rules can call the Work-.AddHistory activity to record their processing.

Diagnosis

Action

Timing of assignments and service levels depends on the internal clock on each Process Commander node and on the server supporting the PegaRULES database.

Ensure that clock on each node are synchronized. See Pega Developer Network article PRKB-10206 How to synchronize server clocks and database clocks with NTP for correct service level computations.

Diagnosis

Action

In a multinode cluster, two or more Data-Agent-Queue instances for the Pega-ProCom agent are enabled. -

To avoid interference and potential locking issues, it is often best to run the Pega-ProCom agent (or at least the escalation portion of it) only on a single node. If multiple copies are enabled, ensure that they use identical RuleSets. Check the Dynamic System Settings data instances that affect agent processing.

Diagnosis

Action

Service level rules for some applications are working, but service level rules for other applications are not working.

When one system supports multiple applications, the Pega-ProCom agent needs access to all the RuleSets that contain service level rules. Update the access group or application rules to achieve this.

Diagnosis

Action

Service level events are occurring, but not on the dates or times expected.

If service level rules have the Business Days check box selected, review the calendar instances that determine which days are business days, and open and closing times for business days. If the calender does not exist, or contains incorrect values, spurious service level dates and times can result.