Published Release Notes

Add additional columns to customized work history tables

The standard work history table, pc_history_work, contains two new columns that return the latitude and longitude coordinate location of the action that prompted the history. Mobile devices can display this location as a street address. If you have a customized work history table, add these two columns to it:

• <decimal name="pxLatitude" size="19" scale="9"/>
• <decimal name="pxLongitude" size="19" scale="9"/>

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.

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>

Using Kerberos authentication with your database

Pega 7 supports Kerberos functionality. Kerberos is a computer network authentication protocol which allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner. 

To use Kerberos for authentication, you must use the command line to install or upgrade Pega 7.

To use Kerberos authentication:

1.  Change the setupDatabase.properties file.

a.  In the “Uncomment this property section” of the file, uncomment the jdbc.custom.connection.properties property.  Based on your security infrastructure, different properties may be required as parameters to this property; provide the needed properties as semicolon-delimited name/value pairs:
 

jdbc.custom.connection.properties=prop1=val1;prop2=val2;prop3=val3;
 

Example:  For an installation on a MSSQL database server from a Windows client machine (where both machines belong to the same Windows domain), using the Microsoft JDBC driver, the property may be set as follows:
 

jdbc.custom.connection.properties=integratedSecurity=true;

b.  Comment out all the username and password properties where they occur in the jdbc.custom.connection.properties file, so that they appear as follows:

# pega.jdbc.username db username
# pega.jdbc.password db password

[lines removed here]

# pega.jdbc.username=ADMIN
# pega.jdbc.password=ADMIN

2.  Set up your database to enable Kerberos functionality.  This may include additional vendor-specific JDBC driver configuration, or other setup procedures.  Check the documentation from your database vendor to determine what Kerberos setup is needed for your database.

3.  Run the command line installation or upgrade by following the instructions found in the Pega 7 Deployment guides.

Run cleanup.bat/sh script only before upgrading

Prior to upgrading the rulebase, you can optionally run the cleanup.bat/sh script to remove older rules from the database.

Run this script before you upgrade your rulebase, or the script may delete needed rulesets. For more information about running the cleanup.bat/sh script, refer to the Upgrade Guide specific to your release version.

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.

When using Oracle 12.1.0.1, left outer joins in reports may return incorrect results

When using  Pega 7 with Oracle 12.1.0.1 , reports that use left outer joins may return incorrect results.

This is an Oracle known issue.  To resolve this behavior, upgrade to Oracle 12.1.0.2, apply the Oracle patch 16726638 by requesting it directly from Oracle, or, for Microsoft Windows installations, apply Windows Bundle patch 12.1.0.1.15 or later.

For more information in this behavior, see: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=392085808201943&id=1957943.1

Custom database (DB) triggers are dropped during upgrade

The latest version of Pega 7 improves performance by no longer using database triggers to assist with System Pulse and Data-Rule-Summary processing, which is now done within the Pega 7 engine. As a result, DB triggers are no longer installed on either the pr_sys_updatescache or pr4_rule_vw tables.

When upgrading to the latest version of Pega 7, if you had previously implemented a custom database (DB) trigger on these tables, or a custom DB trigger that refers to these tables, it is removed during the upgrade process. No custom triggers are removed unless they reference these tables.

If you have custom DB triggers that reference the pr_sys_updatescache or pr4_rule_vw tables and perform other processing, those triggers must be reimplemented. When doing so, you must be careful to not modify the pr_sys_updatescache or pr4_rule_vw tables.

For more information, see Startup check removes custom DB triggers.

Identify, install, and manage hotfixes with the Hotfix Manager

Hotfixes are packages of files that address issues in Pega 7 and in participating Industry Applications. With Hotfix Manager, you can:

• Scan your system for installed and missing critical hotfixes and create a report that you can provide to Pegasystems Support for diagnostic purposes.
• Review the descriptions and contents of hotfixes.
• Install, rollback, and commit hotfixes.
• Manage hotfixes that include schema changes or require other special handling.

The Hotfix Manager replaces the Update Manager Hotfix Installer and System Scanner, both of which are deprecated. For more information, see Hotfix Manager identifies, installs, and manages hotfixes to Pega 7 and participating Industry Applications.

Enhanced product rule form for easy application packaging

The enhanced product rule form allows you to add applications in Delta mode, which includes only the patch version of the rulesets that comprise the application rule. You can also use Global exclusions to exclude one or more rules that are not associated with a ruleset version.

These enhancements allow easy packaging of non-versioned rules that are often deployed separately and reduce the need to manually add them later.

For more information, see Product rules - Completing the Contents tab.