Applies to Pega Platform versions 7.4 through 8.5

Symptoms

Application users see errors in their reports and dashboards, for example, their Compliance Score reports and dashboards. Rules from an application ruleset are not counted in report results, and the dashboard shows the incorrect number of total rules.

Errors

Compliance score report does not include rules from 1 ruleset in the application

Compliance score dash board shows incorrect count of Total rules

Explanation

These symptoms can be caused by a ruleset being defined as both a Standard Ruleset in an Application and as a Production ruleset in Access Group. A specific ruleset name appears only once in the complete ruleset list that is formulated from the Application built-on tree. The ruleset list ordering follows the layers defined in the Help topic, Ruleset list layers. In this Help topic, you can see that Production rulesets are higher up in the ruleset list than any rulesets defined in an application. The Compliance Score is based upon a Report Definition, and that report definition has Filter by application context checked. That’s the real cause of the issue. 

Any Application-filtered report will exclude Production Rulesets. This is by design. The Compliance score report is just one example of this. Any report definition with Filter by application context checked will encounter the same symptom, where the rules in the production ruleset are not included in the report output.

The following example can help explain how an incorrect configuration and incorrect usage of Production Rulesets causes skewed results in reports and dashboards. 

Example

Assume that an Access group named MyApp:Administrator refers to an application named MyApp. The MyApp application contains one ruleset, MyRuleset, which is built on another application named MyFramework. The MyFramework definition shows two rulesets that it contributes to the ruleset list. 

MyFramework

   Rulesets

• FW1:01-01
• FW2:01-01

The MyFramework application will contribute the two rulesets (FW1:01-01, FW2:01-01) into the ruleset list, and they will be placed at the “layer” based upon where the MyFramework application is in the overall list referenced by the Access Group. Therefore, in this example, the resulting ruleset list is this hierarchy:

1. MyApp:01-01
2. FW1:01-01
3. FW2:01-01
4. . . . and so on down the application tree until it ends at the PegaRULES application

On the Access Group definition, the Advanced tab, you can specify a list of Production Rulesets. In our example, if you edit the Access Group to define a Production Ruleset and add FW2:01-01 as a Production Ruleset, this results in the following ordered ruleset list:

1. FW2:01-01
2. MyApp:01-01
3. FW1:01-01
4. . . . and so on down the application tree until it ends at the PegaRULES application

Notice how ruleset FW2 has now jumped to the top of the ruleset list ordering. Because it is a production ruleset containing final overrides for your system, it must be at the top of the ruleset list.  A single ruleset name can appear only once in the ordered ruleset. So, the duplication that exists in the definitions (the Access Group and the MyFramework application) will be reduced to ruleset FW2 appearing in one location only as defined by the highest contributor, which, in this example, is the Access Group.

As a result, the Compliance score dashboard for MyFramework will be skewed: It will not include rules from the FW2 ruleset because that ruleset does not appear in the ordered ruleset list in the “layer” for the MyFramework application.

This is an incorrect configuration and incorrect usage of Production Rulesets. 

Solution

Any ruleset you define in the Production Ruleset list of the Access Group should not be present in the Standard Ruleset list for any application.

Related Content

Ruleset list layers

Production rulesets

Reporting

Report definitions

Managing filter options in Report Viewer