Agents not running after update of EAR-based deployment
Valid from Pega Version 7.1.7
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.
Customized agent schedules for standard Pega Platform agents must be updated after Pega 7.2.2 to Pega Platform 7.3 upgrade
Valid from Pega Version 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. 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.
Upgrading to Hazelcast 4.x requires downtime during upgrades to Pega Infinity 8.6
Valid from Pega Version 8.6
Upgrade impact statement
On-premises upgrades of Pega Infinity release 8.4.2 and later to version 8.5.1 or later on Tomcat and PostgreSQL are completed with near-zero downtime. However, upgrading to Hazelcast 4.x requires that you shut down and restart your application server.
What is required to update the application to be compatible with this change?
Hazelcast 3.x is enabled by default. For near-zero downtime upgrades, you do not need to perform any action.
For instructions about upgrading to Hazelcast 4.x, see one of the following topics:
- For near-zero downtime upgrades from Pega Infinity release 8.4.2 or later on Tomcat and PostgreSQL, see "Optional: upgrading to Pega Platform version 8.6: Upgrading to Hazelcast 4.x" in Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Tomcat and PostgreSQL.
- For all other upgrades, see "Optional: upgrading to Hazelcast 4.x" in the appropriate upgrade guide.
Node types renamed after upgrade from Pega 7.2.2 to Pega Platform 7.3
Valid from Pega Version 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.
Updates no longer require redeploying the prweb.war file or the application server-specific EAR file
Valid from Pega Version 7.1.7
Updating from Pega 7.1.7 to later versions of Pega 7 no longer requires that you redeploy the prweb.war file or the application server-specific EAR file.
Note that upgrades from versions prior to Pega 7.1.7 still require that you redeploy these files.
Rules Assembly cache is deprecated
Valid from Pega Version 7.3.1
Rules Assembly (RA) cache and custom settings for its corresponding fua/assemblyCacheModeprconfig.xml file setting are deprecated because they are obsolete. A warning is logged at startup if a custom (non-default) value is specified for fua/assemblyCacheMode in the prconfig.xml file. The functional behavior of the system is not affected.
Use of PegaRULES_Extract_Marker.txt to delete cache is deprecated
Valid from Pega Version 7.3.1
The PegaRULES_Extract_Marker.txt file is deprecated. The system uses the presence or absence of the PegaRULES_Extract_Market.txt file to determine at startup whether to delete the static content, service export, and lookup list file system-based caches. In the rare situation that you need to delete these caches manually, use the System Management Application (SMA) ETier Static Content Management page. Using SMA does not require restarting the node.
End of support for Microsoft Internet Explorer 9 in Pega 7.2.1
Valid from Pega Version 7.2.1
In accordance with Microsoft’s announcement to discontinue support for Internet Explorer 9, Pega 7.2.1 will not support Internet Explorer 9. You should not upgrade to Pega 7.2.1 if you are still using Internet Explorer 9. Otherwise, upgrade to Microsoft Internet Explorer 10 or later, or use Google Chrome, Apple Safari, or Mozilla Firefox, which support certain HTML5 and CSS3 standards not supported in Internet Explorer 9.
For more information about browser support, see the Platform Support Guide or contact Pegasystems Global Customer Support.
Changes to URL format for Pega Web Mashup
Valid from Pega Version 8.3
The format of Pega Web Mashup URLs now supports multiple mashups on a single web page. The new URL format prevents a mashup from sharing cookies with another mashup.
If you want to include multiple mashups on a single web page and one of the mashups was created before 8.3, you must regenerate the mashup to reflect the new URL format.
For more information, see <link to help topic>.
Rules can no longer access Pega internal Java packages
Valid from Pega Version 8.4
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.