Published Release Notes

Clear and actionable guardrails help you mitigate risk sooner

The Application Guardrails landing page has been restructured to give you an executive-level view into your application health. Use the available metrics and tools on each tab to understand the scope of warnings in your application, the operators responsible for introducing this risk, and ways to improve your compliance score before your development goes into production.

Include this landing page in your governance process to:

• Understand your application compliance score and how it has changed over time:

  • A score of 90 or greater indicates your application is in good standing.

  • A score of 80-89 indicates your application needs review for improvement.

  • A score below 80 requires immediate action.

• Investigate the factors contributing to your score, such as warning age or severity, and the rules and operators associated with each warning.
• Review a comprehensive list of warnings and the recommended path to resolve them.
• Communicate all of these details to project stakeholders through email or exported documents.

​

Available metrics on the Compliance Details tab of the Application Guardrails landing page

The Charts tab in this landing page has been superseded by the Compliance Details tab, which provides more options and an enhanced presentation.

For more information about the available features on all tabs in this landing page, see Application Guardrails landing page.

Rollback functionality is limited to latest revision

The rollback functionality in DSM Revision Manager allows customers to roll back the import of the latest revision to their DSM application. Only one rollback is allowed; after a rollback, the rollback option is disabled until the next revision is imported. If importing two (or more) revisions at once then attempting a rollback, the system only rolls back one revision.

Example: a user has a base DSM application. They import Revision 1, and then import Revision 2. Next, they try to roll back both revisions. The system reverts to the Revision 1 version of the application, and the customer cannot revert all the way back to the base application.

Action required by admins for improved search

Starting November 13, 2014, after updating to or upgrading from a prior version to Pega 7.1.7, your system administrator must manually build all indexes for Elasticsearch before the system can automatically switch from Lucene to Elasticsearch.

It is recommended that you begin this manual re-indexing process for all enabled index types as soon as your update or upgrade is complete. The search landing page refers to Elasticsearch settings; during re-indexing, however, Lucene search continues to function to ensure that there is no interruption in search functions. When planning the re-indexing, be aware that the initial re-indexing requires significant resources on the host node and can be a lengthy process, depending on the number of rules and work objects in your system.

See the Pega 7.1.7 Upgrade Guide for information about manually indexing Elasticsearch.

System Management Application displaying listeners that do not require any action

After installing or upgrading to Pega 7.1.7, there is an additional available listener (Data-Decision-DNode-Service:Default) that does not require any action. This listener can be safely ignored and you should not use the System Management Application to manage any of its operations or state.

• The Data-Decision-DNode-Service:Default listener is always running on every PRPC node.
• The state of this listener is internally managed by PRPC. Starting or stopping it through SMA does not have any effect on its state.

Open ports required for cluster communication

In a Pega 7 system, there can be multiple servers, or nodes, and each node can contain multiple JVMs.  In Pega 7.1.7, the port range 5701-5800 needs to be left open for cluster communication.   The number of available ports in this range needs to be greater than or equal to the greatest number of JVMs on any one node in the cluster.  So for example, if there are 3 JVMs on one node, and 7 JVMs on another node, there need to be at least 7 ports available.  By default, the system will begin with port 5701, and then look for the next port in the sequence (5702, followed by 5703).

If these ports are not available, you will see the following error:

ERROR   - PegaRULES initialization failed. Server: ABCDEF123

com.pega.pegarules.pub.context.InitializationFailedError: PRNodeImpl init failed

< . . . Java dump here . . . >

Caused by: com.hazelcast.core.HazelcastException: ServerSocket bind has failed. Hazelcast cannot start! config-port: <port>, latest-port: <port>

Password hashing using SHA-256/SHA-512

Password hashing using the SHA-256 and SHA-512 hash functions is available for use during the the Pega 7 authentication process with operator, ruleset, and update lock passwords. The SHA-256/SHA-512 hash functions join the previously available MD5 and SHA-1 hash functions.

Using SHA-256/SHA-512 hashing when creating or upgrading a password hash results in increased complexity of the hash, making it extremely difficult and time-consuming to determine hashed password values stored in a database.

Note that once you have updated your system to Pega 7.1.7 and have applied password hashing using the SHA-256/SHA-512 hash functions, reverting back to a previous version of Pega 7 is not advised as this causes hashed passwords using SHA-256/SHA-512 to fail.

See About password hashing for more information.

Recommended heap sizes

The heap is a storage area in the Java virtual machine (JVM) allocated for both short-term and long-term (shared) object storage. If the server does not have enough memory allocated to run Pega 7, the system can hang without an error message. If this occurs, your values need to be higher than the recommendations based on your server hardware and the number of other applications on the server.

Pegasystems recommends using these settings:

• Initial Heap Size (Xms): 1 GB
• Maximum Heap Size (Xmx): 12 GB (8 GB minimum)

If your application server is using the Oracle JVM, also add the PermSize and MaxPermSize settings:

• PermSize (-XX:PermSize): at least 256MB
• MaxPermSize (-XX:MaxPermSize): at least 512MB

Set the JVM memory options to increase the amount of system memory allocated to the application server running Pega 7 by selecting Designer Studio > System > Operations > System Management Application and then selecting a listed node.

See the Pega 7.1.7 Installation Guides for more information about how to make these setting changes.

Cannot create new data tables after update

Data tables have been replaced by a new local data storage format. You can upgrade old-style data tables to use the new local data storage format, but the new format is not compatible with earlier versions of Pega 7 in which data tables could be created.

You can still edit legacy data tables by using the old data table functionality. However, to create new data tables, you must use the Data Explorer and Data Designer.

Updates no longer require redeploying the prweb.war file or the application server-specific EAR file

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.

The System Management Application is supported only on Microsoft Internet Explorer

Microsoft Internet Explorer (IE) is required for the System Management Application (SMA). No other browser is supported.