Published Release Notes

Tomcat log files moved to work directory

For Tomcat application server users, the default path for PRPC logs has been changed to the "work" directory for Catalina. For example:

<tomcat>\work\Catalina\localhost\prweb

This directory can be cleaned up during administration. To avoid loss of files, you can redirect logging to a different directory after installation:

1. Navigate to the <tomcat-home>\webapps\prweb\WEB-INF\classes directory.
2. Open the prlogging.xml file.
3. Locate the "appender" definitions section that contains the "@{web.tmpdir}" string
4. Update the FileNamePattern values to point to the new directory.

For more details, refer to the “Change the default path to PRPC logs” section in the Tomcat installation guide for your database.

Additional upgrade scripts for new columns

In Version 6.2, additional columns (Major, Minor, and Patch) containing ruleset Version information were added to 15 tables in the PRPC database. When upgrading from a pre-Pega 7 release, scripts must be manually run after the upgrade to populate these columns.

These scripts are located in the Resource Kit, under Additional Upgrade Scripts.

• If upgrading to a single schema, run both scripts.
• If upgrading to a split schema, run the _data script against the data schema and run the _rules script against the rules schema.

Choose the scripts for your database type:

• db2zos_rulesetversion_columns_data.sql
• db2zos_rulesetversion_columns_rules.sql

• mssql_rulesetversion_columns_data.sql
• mssql_rulesetversion_columns_rules.sql

• oracle_rulesetversion_columns_data.sql
• oracle_rulesetversion_columns_rules.sql

• postgres_rulesetversion_columns_data.sql
• postgres_rulesetversion_columns_rules.sql

• udb_rulesetversion_columns_data.sql
• udb_rulesetversion_columns_rules.sql

Slow WebSphere performance on Mac platforms

Use the following JVM setting to improve WebSphere performance on Mac platforms:

-Djava.net.preferIPv4Stack=true

Split schema systems require additional privileges

On Oracle split schema systems, add the following database privileges:

• Grant DROP ANY INDEX to the Admin User.
• Grant UNLIMITED TABLESPACE to the Rules User.

Use the Oracle Enterprise Manager to add these privileges or refer to the 7.1.3 Upgrade and Installation guides for Oracle.

Database

Improvements to data handling were made for search indexing, agent processing, and filtering.  Scripts were provided for proper population of the database tables.

• Importing data from shared obj-external tables is now supported.
• A validation warning will now display when an unexposed property is used in filter or join conditions.
• A Global Search index may now be created across two databases.
• Agent processing on multiple nodes has been improved.
• Improvements were made to controls in Report Definition pages which are used in a dynamic grid.
• Filtering functionality involving special characters has been enhanced.
• Scripts have been provided to populate the RuleSetVersion Major, Minor, and Patch columns.

System Management

Refinements were made to out-of-place upgrade documentation and processes, as well as for how handling is performed for all of the database vendor specific nuances related to a deploying into a split schema environment.

• A script was created to run the data schema upgrade for z/OS systems.
• In a split-schema configuration, indexing has been enhanced.
• The product installer has been enhanced.
• The stand-alone Static Assembly Utility does not require a password for its process.
• The UpdateManager tool has been improved.

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.

Updated Rule-Utility-Function resolution

Rule-Utility-Function rules are now resolved based on ruleset.

Previously, if you had the same function @xyz() in different libraries in different rulesets, you could not call the function by using @xyz, because that would throw an exception.

The resolution process has since been updated so that rule resolution is now based on the highest ruleset in context. This update makes the function resolution process consistent with how rule resolution is performed for other rule types.

For more information, see Functions in expressions.