Published Release Notes

Unit testing support for more rule types

You can now create unit tests for the following additional rule types. You can also create assertions to validate activity status. The expanded rule types for unit testing enable developers to more thoroughly perform regression testing of their application, thereby improving application quality.

• Collection
• Declare expression
• Map value
• Report definition

For more information about unit testing rules, see Pega unit test cases.

Upgrade impact

With the four new rule types, unit test execution and unit test compliance metrics will change. Reports on automated unit testing of the customer application decrease due to the increased pool of supported rules.

What steps are required to update the application to be compatible with this change?

After a successful upgrade, create Pega unit test cases for the newly supported rules to see updated and accurate unit test metrics.

Test coverage support for more rule types

Test coverage has been expanded to include the following rule types. Test coverage support for these rule types enables developers to more accurately measure the effectiveness of their tests.

• Collection
• Declare trigger
• Map value
• Navigation 
• Report definition
• Scorecard

For more information about test coverage, see Test coverage.

Upgrade impact

The new rule types may impact the test coverage metrics for your applications. Due to the increased number of supported rules, the reported test coverage percentage will decrease.

What steps are required to update the application to be compatible with this change?

Run your coverage reports after upgrading to see the latest metrics.

Updated default dynamic system setting for requestor pools

Clients can now enable or disable requestor pools for processing service requests using a new dynamic system setting called EnableRequestorPools with Pega-IntegrationEngine as the owning rulest. Previously, all deployments utilized requestor pools to improve service processing response efficiency; requestor pools eliminated overhead by automatically returning a requestor to the pool after it fulfills a service request. Starting in Pega Platform 8.4, requestor pools are disabled in Client-managed cloud deployments, since these deployments use autoscaling to handle service request traffic. Enabling requestor pools in Kubernetes environments is not recommended, because they can inhibit the default autoscaling settings in the environment.

Requestor pools remain enabled by default in Pega Cloud and on-premises environments.

To help clients navigate this change, Pega has updated its best practice guidance for configuring requestor pools. For an overview, see Requestor pooling for services. For guidance on the use of requestor pools in your application, see the EnableRequestorPools entry in Dynamic system settings data instances.

Upgrade impact

Requestor pools are disabled by default in Pega Platform 8.4 in client-managed cloud deployments. Clients who deployed previous versions of Pega Platform on a Kubernetes environment and who upgrade to Pega Platform 8.4 could see that their services behave differently.

What steps are required to update the application to be compatible with this change?

If clients that are deployed in a Client-managed cloud environment need to configure their services to use requestor pools and they understand how to configure requestor pools for their optimized use, these clients can re-enable requestor pools. Clients should review the best practice for configuring requestor pools before they re-enable requestor pools. To re-enable requestor pools, you modify the EnableRequestorPools setting in the Pega-IntegrationEngine Owning ruleset from “disabled” to Enabled [no value]. For details, see Editing a dynamic system setting.