Published Release Notes

Extract data from Pega Cloud to an on-premises database

You can now use Pega^® Business Intelligence Exchange (BIX) to extract data from Pega Cloud to an on-premises relational database management system. Extracting data from Pega Cloud directly to an on-premises database improves efficiency by eliminating the need for file extraction and the development of a file extraction infrastructure.

For more information, see Extracting data from Pega Cloud to an on-premises database.

Improved connection pooling performance

HikariCP is now used for connection pooling for databases that are configured by using a URL. HikariCP improves connection pooling performance; however, more database connections might be used than in previous versions of Pega^® Platform.

As a result of the switch to HikariCP, you cannot use the System Management Application (SMA) to get diagnostic data from your application. For instructions about how to get diagnostic data by using REST services, see Obtaining connection pool diagnostic data by using REST services.

No longer supported translator configuration options

The following translator configuration options are not needed and are no longer supported. If you previously configured any of these system settings, remove them from the system settings to avoid a warning message. For example, if you set translator/useparserfamily, the following message is displayed at startup: "Translator option, 'translator/useparserfamily' is not needed and no longer supported. Remove this from the system settings."

• translator/useparserfamily
• translator/usecodegenerator
• translator/usenativedouble
• translator/optimization/use71BlockAnalysis
• translator/optimization/use71ConstantFolding
• translator/optimization/use71AssignmentTypeSimplification
• translator/optimization/use71IntrinsicFunctions
• translator/use71PropSetGeneration
• translator/use71ParserAssignment
• assembly/model/useBlock4ContiguousSets
• /translator/pandc/comparepandcalgorithms
• /translator/pandc/use6xalgorithms
• /Compatibility/CheckForTopLevelClassMismatch

In addition, the com.pega.pegarules.generation.parseoverride bootstrap option is no longer supported. Remove this option from the system settings.

System state data is saved for 90 days

System state data is now saved to the database for 90 days and can be downloaded as a JSON file. Having previous system state data available is useful for debugging system problems. Operators with the pzSystemOperationsObserver privilege can download system state data from the Cluster Management landing page for either the entire cluster or a single node. In addition, the PersistClusterState and PersistNodeState agents have been added to the Pega-RulesEngine ruleset for persisting system state data to the database.

For more information, see Downloading the system state.

PegaDATA connection settings now required in the prconfig.xml file

If you use the default prconfig.xml file that is included with Pega^® Platform, and you have not removed the PegaDATA connection settings, no action is required. If you use a custom prconfig.xml file, for example, for running tests, ensure that the database connection settings for PegaDATA are not blank.

For more information about the connection settings, see PegaDATA connection settings in the prconfig.xml file.

Node classification replaces NodeID-based configuration

For simpler cluster administration and better application resiliency, Pega^® Platform is moving toward a node classification model. Although agents will continue to work by using NodeIDs for several upcoming releases, use node types instead of NodeID configuration for agents, listeners, and decisioning services for more efficient operations and upgrades.

For more information, see Node classification.

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.