Published Release Notes

Agents not running after update of EAR-based deployment

If you update an EAR-file deployment and your update meets both of the following criteria, you must redeploy the prpc_*.ear file for your application server after you complete the update to avoid agent-related errors:

• Updating from Pega 7.1.7, Pega 7.1.8, or Pega 7.1.9
• Updating to Pega 7.1.10, 7.1.11, 7.2, or 7.2.1

If you do not redeploy the prpc_*.ear file, you will see the agent-related issues that are described in the support article Agents are not running.

For information about redeploying, see the Pega 7 Platform Update Guide for your target version of the Pega 7 Platform.

Deployment Manager on Pega Cloud Services

Pega Cloud Services introduces Deployment Manager support, a service that is automatically installed and configured in Pega Cloud environments running Pega Platform 7.4 and higher. Deployment Manager on Pega Cloud allows you to manage the deployment of your Pega Cloud applications through staging to production environments. For details see Deployment Manager 03.01.01.

Customized agent schedules for standard Pega Platform agents must be updated after Pega 7.2.2 to Pega Platform 7.3 upgrade

If you used node classification in Pega^® 7.2.2, when you upgrade to Pega 7.3, node type names are automatically changed to a new name when you start a node with a node type. Agent schedules for standard Pega Platform agents are deleted and re-created with the new node type name, but any customization that you made in Pega 7.2.2 is not saved. You must manually update the agent schedules for standard Pega Platform agents in Pega 7.3.

For more information, see Node types renamed after upgrade from Pega 7.2.2 to Pega Platform 7.3 and the appropriate Deployment Guide.

Verifying that a Pega 7 Platform instance is running

You can verify whether a Pega 7 Platform instance is up and running by entering this URL: http://<<hostName:port/contextName>>/PRRestService/monitor/pingservice/ping

The Pega 7 Platform Engine responds with HTTP Response Code 200 if the instance is available. The response contains JSON text in the format { "duration":"<time in milliseconds>" }. Any other response codes or timeout indicate that the instance is unavailable.

MBeans deprecated in favor of Pega API

The use of MBeans for cluster management has been deprecated, although MBeans will continue to function for legacy deployments. The recommended best practice for automating system management is to use the Pega API. For more information, see Pega API.

Pega 7 Platform supports X-Forwarded-* (XF*) HTTP headers

When deployed behind a load balancer, the Pega 7 Platform can formulate absolute URLs while responding to requests, without any additional configuration. The load balancer must be configured to use XF* headers. Consequently, the configuration property contextrewriteenabled is deprecated.

Improved Pega 7 Platform upgrade and update time

The Pega 7 Platform upgrade and update tools have been improved to streamline indexing. Upgrading and updating are faster than with previous releases.

Node types renamed after upgrade from Pega 7.2.2 to Pega Platform 7.3

If you used node classification in Pega^® 7.2.2, when you upgrade to Pega 7.3, node type names are automatically changed to a new name when you start a node with a node type.

• UniversalNode becomes Universal
• WebUserNode becomes WebUser
• BackgroundProcessingNode becomes BackgroundProcessing
• BIXNode becomes BIX
• SearchNode becomes Search

If you created agents in Pega 7.2.2, agent schedules are also automatically updated with a new name during the upgrade. For more information, see Customized agent schedules for standard Pega Platform agents must be updated after Pega 7.2.2 to Pega Platform 7.3 upgrade and the appropriate Deployment Guide.

Pega 7 Platform startup fails with an evaluateWhen-Exception after upgrade

If the batch requestor, Data-Admin-Requestor.BATCH, does not have access to the PRPC:Agent access group, the Pega 7 Platform fails to start up after an upgrade. The checkSecurity step fails with an evaluateWhen-Exception while evaluating access to the Data-Admin-System-Settings.pzSharedTenant when rule.

To resolve this issue, follow these steps:

1. On the pre-upgraded environment, grant the Data-Admin-Requestor.BATCH access to the PRPC:Agents access group. See the online help for information about granting access to access groups.
2. Move the database table record that corresponds to the batch requestor type from the pr_data_admin table of the pre-upgraded environment to the pr_data_admin table on the upgraded environment. See the online help for information about moving database table records.

View the configuration settings for Pega Platform nodes in Designer Studio

On the new Configuration Settings landing page, you can view a list of the configuration settings for a specific node, current or remote, or for an entire cluster. From this landing page you can diagnose settings issues, determine whether settings are loaded correctly, and review the settings' purposes. You can also download the prconfig.xml file for any node in a cluster to modify the settings. The ability to view settings for all nodes in the Cluster from a single landing page makes diagnosing configuration issues across the cluster simpler and easier than logging on to each node individually to view its system settings. For example, if a started agent does not run, you can check if agents are enabled on your system; or if some of your caches are too big, you can check the setting for the cache size. You can also determine if settings are loaded correctly, and identify discrepancies in the settings across the nodes.

For more information, see Viewing the current configuration settings of a node or the whole cluster, Downloading and viewing the prconfig.xml file for a specific node, REST APIs for viewing the configuration settings for Pega Platform.