Published Release Notes

Greater cluster stability with client-server clustering topology

You can now deploy Pega^® Platform in the new client-server clustering topology that uses Apache Ignite, which increases stability in large clusters and provides independent scalability for both servers and clients. This technology separates the client nodes, which are responsible for Pega Platform processes, from the server nodes, which are responsible for cluster communication and distributed features. If your production environment consists of more than five nodes in the cluster, it is recommended that you switch to the new client-server topology.

For more information, see Apache Ignite client-server clustering topology and the appropriate Deployment Guide.

View and apply schema changes when upgrading or updating

When you upgrade or update, you can view the schema changes to the default work and history tables and apply the changes to your cloned tables. By applying the changes, you improve performance and can take advantage of the latest reports on those tables.

For information about viewing and applying schema changes as part of the upgrade or update, see the Pega 7 Platform Upgrade Guide or the Pega 7 Platform Update Guide.

For information about using the Designer Studio tool or the command-line tool, see Updating cloned tables after an upgrade or update.

Improved indexing performance by gradual retrieval of data

Search functionality in Pega Platform™ versions from 8.4.5 to 8.6 now includes the option to improve indexing performance when reading query results from a large table in a database. For example, to load the recommended 50 records at a time, in the Pega-SearchEngine ruleset, create the indexing/distributed/fetchsize dynamic system setting, and set the value to 50.

Creating the fetchsize dynamic system setting ensures that your system does not crash while indexing classes with numerous instances.

For more information, see Creating a dynamic system setting.

Existing operator IDs during upgrades and updates

Upgrades and updates are always performed in secured mode to help prevent unauthorized access to your system. In secured mode, the [email protected] operator ID is always overwritten, but other existing standard operator IDs are not modified. New operator IDs are inserted in secured mode. For more information, see the Deployment Guide for your environment.

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

Import only new instances of specific classes

To bypass updates for specific classes and only import new instances of those types, edit the product rule definition.  For more information, see Specifying product rule deployment options.

REST APIs added for management of agents and requestors

You can use new REST APIs to download a module version report or manage requestors and agents in Pega Platform™. For example, you can use a requestor REST API to end a requestor process, and you can use an agent REST API to start or stop an agent. These APIs allow external systems to report and manage Pega resources.

For more information, see Pega API for Pega Platform and Pega API.

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. 

Changes in JSON results when checking the health of your system

Beginning with Pega Platform™ 8.2, the JSON results that are returned when you ping a Pega Platform instance have changed. JSON results now include node type and health information, including test name, status, state, and node ID. The following samples show JSON results from versions before 8.2 and as of 8.2.

JSON results for pre-Pega Platform 8.2:

{ "duration":"3954.448601", "count":"0" }

JSON results for Pega Platform 8.2 and later:

{"node_type":["WebUser"],"health":[{"last_reported_time":"2019-02-14T16:10:49.589Z","test_name":"Sample-Stream-Check","status":"success"}],"state":"healthy","node_id":"10.10.10_samplenode"}.

REST API now fetches the latest version of Application Quality metrics

When you request Application Quality metrics by using the REST service, the service requests a refresh of the metrics. This means that you always get the latest version of the metrics and can decide whether your application is ready for deployment based on that information.

For more information, see Pega API.