Open access to quiesced servers when using immediate drain
Valid from Pega Version 7.2.1
When using the immediate drain method to perform quiesce on a node, any operator can now access a quiesced server for root cause analysis or remediation, regardless of their user role or privileges. For quiesced server access when using the slow drain method, you must still include either the PegaRULES:HighAvailabilityAdministrator or PegaRULES:HighAvailabilityQuiesceInvestigator user role in a user's access group. Administrators using the slow drain method without either of these user roles are exiled from the quiesced node and are redirected to an active node.
For more information, see Immediate drain available for quiesce when using high availability.
New passivation and activation activities
Valid from Pega Version 7.2.1
Two new activities have been implemented, pyPrePassivation and pyPostActivation, which are run every time operator passivation occurs, regardless of the node quiesce state. These activities save and restore the requestor state during passivation and activation. In order for the pyPrePassivation or pyPostActivation activity to be run as expected, you must implement the activity by using the correct Applies To class (@baseclass).
The previous activities that were run during the quiesce process, pyPreQuiescePassivation and pyPostQuiesceActivation, have been deprecated.
For more information, see the Pega 7.2.1 High Availability Administration Guide.
Support for reserved keywords in database column names
Valid from Pega Version 7.2.1
Databases use reserved keywords such as Group, Order, Rank, and Date to define and manipulate data. The list of reserved keywords is specific to each database. Column names can now include reserved keywords.
High number of busy waits when using Oracle SecureFiles
Valid from Pega Version 7.2.1
You might experience a high number of buffer busy waits when using Oracle SecureFiles for BLOB storage. An Oracle buffer busy wait occurs when a session cannot access a database block in the buffer cache, because another session is either reading the block into the buffer or changing the buffer. As a best practice, use Oracle 11.2.0.4 or later, because earlier versions have more problems with SecureFiles. In addition, to minimize the number of busy waits, set the hidden Oracle parameter _securefiles_concurrency_estimate to 50, and partition the table by using a composite range hash partition that is based on the pxCreateDateTime and pzInskey columns.
For more information, see Troubleshooting: High number of busy waits when using Oracle SecureFiles.
View and apply schema changes when upgrading or updating
Valid from Pega Version 7.2.1
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.
Discontinued support for multithreaded requestors
Valid from Pega Version 7.2.1
Multithreaded requestors are no longer supported in the Pega 7 Platform. Multithreading was previously specified by the prconfig setting initialization/allowMultiplePRThreads. If this setting is set to true when you upgrade to Pega 7.2.1, errors occur during the quiesce process.
Support for data rollback and commit in service-enabled system management
Valid from Pega Version 7.2.1
You can use the service-enabled manage tracked data tool to roll back or commit data that has been imported with the service-enabled import tool.
The service-enabled manage tracked data tool lets you commit imported data or roll back all non-committed data instances to their state immediately prior to when they were imported. The tool only tracks and supports rolling back data instances that do not belong to the PegaRULES database name (Data-Admin-DB-Name).
For more information, see Rolling back and committing tracked data.
Child case queries can be slow after upgrade
Valid from Pega Version 7.2.1
After upgrading, performance might be slow when you run queries on child cases for work tables that existed prior to the upgrade. This issue is often indicated by PEGA0005 (query time exceeded limit) alerts that can be correlated to these queries in the logs. To resolve the issue, add a database index to each of your work tables by using a multicolumn index on the pxCoverInsKey, pxObjClass, and pyStatusWork columns.
For more information, see Performance improvements for child case queries.
Verify ML Readiness error: Upgrades from Pega 7.1.0 through 7.1.8 do not replace nonversioned rules
Valid from Pega Version 7.2
Upgrading from any Pega 7 Platform version between Pega 7.1 and Pega 7.1.8 to Pega 7.2 does not automatically replace nonversioned rules. If you revalidated and saved a Pega 7.1.x rule after the timestamp on the Pega 7.2 version of the rule, upgrading to Pega 7.2 does not overwrite the saved rule. You might see either of the following behaviors:
- The upgrade fails with the following error message:
Verify ML Readiness - The upgrade succeeds, but you might be unable to open changed rule forms.
If the upgrade fails, see the Pega 7 Platform Upgrade Guide to force the upgrade.
This known issue does not affect Pega 7.1.9. After the upgrade has finished, apply Hotfix 27288. For information about obtaining and applying hotfixes, see Hotfix Manager.
Improved engine startup times
Valid from Pega Version 7.2.1
Performance enhancements in this release decrease engine startup times for new Java virtual machines (JVMs) and improve rule assembly for libraries. JVM startup times are faster because rule utility libraries and functions are no longer generated at startup. For more information, see Extract marker file not created at startup.