Skip to main content

Published Release Notes

Find release notes for the selected Pega Version and Capability

Browse resolved issues for Platform releases.

This documentation is for non-current versions of Pega Platform. For current release notes, go here.

Simulation of data pages and third-party connections

Valid from Pega Version 8.4

When configuring your unit test case environment, you can now set up simulated data for connector and data page rules, instead of connecting to external sources.

By simulating such data calls, you are not dependent on any third-party server when running your tests.

This feature supports the following rules:

  • Data page
  • Connect-Cassandra
  • Connect-CMIS
  • Connect-dotNet
  • Connect-EJB
  • Connect-HBase
  • Connect-HTTP
  • Connect-Java
  • Connect-JMS
  • Connect-MQ
  • Connect-REST
  • Connect-SAP
  • Connect-SAPJCo
  • Connect-SOAP

For more information about simulating third-party connections, see Simulating data pages and third-party connections.

New branch quality dashboard

Valid from Pega Version 8.4

Pega Platform™ 8.4 introduces a new branch quality dashboard that shows the following metrics:

  • The branch’s guardrail compliance score and the number of guardrail violations
  • The percentage and number of unit tests that passed for the branch
  • The percentage and number of rules that the tests cover
  • Potential merge conflicts that can be addressed directly from the branch quality dashboard

For more information about the new branch quality dashboard, see Viewing branch quality and branch contents.

Autopopulated properties support savable data pages

Valid from Pega Version 8.4

To more easily source data, you can now save an autopopulated property that references a savable data page. For properties that you autopopulate by copy, save plans now execute on the copy, instead of on the data page. These enhancements reduce implementation time and make the applications that you build more manageable.

Rules can no longer access Pega internal Java packages

Valid from Pega Version 8.4

You can no longer create rules that access Java packages that reference internal APIs (syntax com.pega.platform.*.internal*). This change does not affect rules that access Pega public API packages.

If you encounter issues when running existing rules that reference internal Pega APIs, contact Pega Support.

Upgrade impact

After an upgrade to 8.4 and later, clients can no longer save new or modified rules that access Pega internal APIs; existing rules that reference internal APIs can still be run but cannot be modified. 

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

Following a software upgrade to 8.4 or later, clients can refactor existing rules into guardrail compliant rules. To find rules to refactor, run the validation tool from designer studio (Application > Tools > Validation) to identify what rules fail validation; failed rules that include the message "Test compilation failed : Illegal internal class reference : com.pega.internal.XYZ" can updated to reference appropriate APIs.

Client-server deployment of Hazelcast

Valid from Pega Version 8.4

Pega Platform now supports the client-server model for the Hazelcast service, which provides cluster communication and distributes Pega Platform features across nodes. This optional deployment model introduces independent scalability for both servers and clients in Pega Platform, improving stability for deployments that use a large number of nodes.

The Hazelcast client-server model is intended for select environments running Pega Platform 8.4 across a large number of nodes and should be deployed only when directed by Global Client Support.

Updated default dynamic system setting for requestor pools

Valid from Pega Version 8.4

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.

Enhanced reliability and stability of scenario tests

Valid from Pega Version 8.5

Several enhancements have been made to scenario tests to increase their stability and reliability. With enhanced improvements, you can now:

  • Delay the execution of a step within a scenario test to add latency to a web browser and actions on a web page. This prevents tests from failing when a dynamic web page does not load all page element at once, but the test finds page elements that are immediately rendered.
  • Automatically rerun failed scenario tests, which might fail because there are temporal stability issues on the environment or because the application UI is slowly renders.
  • View the run history of scenario tests so that you can analyze the history of a test over time.

For more information, see the following:

Automate business process tracking by importing Excel files

Valid from Pega Version 8.5

To track business processes status and data, you can now import Excel files when you create a case or data object in App Studio. This functionality provides the following enhancements:

  • You can now upload a CSV file when you create a case or data object in App Studio. By importing a CSV file, you can use the data in your spreadsheet to define your data model.
  • You can generate a data import template that you can use to import a file in its original format during production.
  • You can upload .xlsx files to avoid resaving your Excel file as a CSV file.

For more information, see Creating a data model from a spreadsheet.

Data APIs support data exploration in React UI tables

Valid from Pega Version 8.5

Data APIs have been enhanced to support filtering, sorting, paging, and aggregation in React UI tables. You can use that functionality to access your data quickly and intuitively. For example, by using paging, you can query a data page to retrieve the second page of an employee contact list and specify the number of results that are displayed on the page.

For more information, see Data API performance and limitations.

Support for application-specific REST API calls

Valid from Pega Version 8.5

You can now call an authenticated REST API in the context of any application that is listed on an operator record by using the application alias URL. With the application alias URL, you can also develop REST services without changing the access group in the service package. REST services run in the context of the access group that points to the provided application, instead of the access group that is specified in the service package.

For more information, see Invoking a REST service rule.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us