Published Release Notes

Specify the scope for rolling back rules and data to a restore point

Create restore points to save the state of all rules and data in your system at a significant point in time, for example, before you import an application. Roll back to that restore point to return the system to that state. Now, you can filter which rule and data instances are returned to their previous state:

• System: Roll back every rule and data instance that has a history record.
• User: Roll back rule and data instances modified by a specific user. If any rule was changed by more than one user, you will see an error message and must use the system rollback.
• Application: Roll back rule and data instances in a specific application.

For more information, see Using restore points to enable error recovery.

Rules can no longer access Pega internal Java packages

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

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

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.

Automatically update dependent applications to use the latest versions of built-on applications

You can now automatically update dependent applications to use the latest versions of built-on applications. When you import an archive that you created from a product rule, you can update all dependent applications to be built on the latest application versions in the archive.

For more information, see Updating dependent applications with the latest versions of built-on applications.

Alerts for long-running queue processor and job scheduler activities

Pega Platform™ now saves an alert in the performance alert log when a queue processor activity or a scheduled job runs longer than the configured threshold value. Use the alerts to identify potential performance issues with long-running processes.

The alerts are enabled by default. You can change the alerts for dedicated queue processors and job schedulers at the rules level. For standard queue processors, you can also set the threshold value for the Queue-For-Processing command in an activity. You disable the alerts in dynamic system settings.

For more information, see:

• PEGA0117 alert: Long-running queue processor activity
• PEGA0118 alert: Long-running job scheduler activity

Introduction of Search and Reporting Service

Pega Platform™ now uses Search and Reporting Service, which is an independent microservice. The new enhancement provides a convenient way to manage your application data, and is easier to maintain. For example, because of the cloud-based architecture of Search and Reporting Service, any bug fixes and performance improvements occur seamlessly, and have no impact on your overall experience in Pega Platform.

For more information, see Search and Reporting overview.

Ability to restrict access to the Import wizard

You can now restrict access to the Import wizard so that users implement an automated pipeline to deploy changes between environments such as staging and production. Deployment Manager is one method by which to create pipelines. By using pipelines to propagate changes, users can apply a standardized and automated deployment process for migrating their applications.

For more information, see:

• Ensuring that users migrate applications with a pipeline by restricting the Import wizard
• Understanding model-driven DevOps with Deployment Manager

Optimized data schema upgrade

Several improvements have been made to optimize the speed of the data schema upgrade to help you experience minimal downtime during upgrade to Pega Platform 8.5™. The data schema upgrade process optimizations include the following improvements:

• Optimized database index creation during upgrade
• Optimized synchronization process to detect duplicate rules during the application import process
• A new upgrade setting for Pega Cloud® Services operators that reduces the time to upgrade clients that run large Pega applications, such as the CRM Suite

For more information, see Limit upgrade downtime with data schema upgrade improvements (8.5).

Support for hotfix file verification

Pega Platform hotfix files are now digitally signed so that they can be verified and authenticated. If your Pega Platform™ instance allows outbound URL connections, hotfix files are verified automatically during installation. If your Pega Platform instance does not allow outbound URL connections, you can verify the files manually by using third-party tools. Alternatively, if your Pega Platform instance does not allow outbound URL connections and you do not use third-party tools to verify hotfix files, you can import a certificate revocation list (CRL) for Pega Platform to use when checking the files to see if they have been revoked. 

For more information, see Verifying the authenticity of hotfix files.