Published Release Notes

Option to resume failed upgrades and updates

When you upgrade or update to Pega 7.2.1, you can opt to have the system resume the deployment after a failure to avoid restarting the deployment and to save time. The deployment resumes at the point of failure and does not repeat any successful steps. This functionality is not supported for new installations. For more details, see the Pega 7 Platform Upgrade Guide and the Pega 7 Platform Update Guide.

Improved application performance when responding to SOAP requests

When an application serves multiple requests, the contention placed on the ContextHash class is reduced because all threads can concurrently access the mHash instance variable, which improves performance. To experience this benefit, redeploy the prweb.war file for web tier deployment or redeploy the prpc_wls_jee4.ear file for e-tier deployment.

X-Forwarded-Host field is optional for HTTP proxy servers

Prior to Pega^® Platform 7.3, the X-Forwarded-Proto and X-Forwarded-Host fields were both required to deploy Pega Platform instances behind an HTTP proxy server. Some proxy servers or load balancers (for example, Amazon ELB) do not support the X-Forwarded-Hostfield. Starting with Pega 7.3, only the X-Forwarded-Proto field is required. For more information, see Deployment behind a reverse proxy.

Elasticsearch 2.4.0 upgrade

The Pega 7 Platform has been updated to use Elasticsearch 2.4.0. You do not have to reindex immediately. You can reindex at your convenience by using the FullTextindexer utility, which provides a smoother transition to the next Elasticsearch library upgrade.

Rolling upgrades are not supported. Instead, after the upgrade has been completed, shut down all the nodes in the cluster, and then restart them beginning with the indexing nodes. For more information, see the Pega 7 Platform Upgrade Guide on the Deployment Guides landing page.

Data model inheritance does not depend on ruleset context

Search and Reporting Service (SRS) in Pega Platform™ 8.6 now provides an improved method of synchronizing data model by distinct users. In applications built on earlier versions of Pega Platform, some users might encounter difficulties in indexing data. Now, the data model that the system sends to SRS does not depend on access privileges. With this enhancement, each user of your application is eligible to synchronize data.

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