Skip to main content

Published Release Notes

Find release notes for the selected Pega Version and Capability

Browse resolved issues for Platform releases.

This documentation is for non-current versions of Pega Platform. For current release notes, go here.

Additional upgrade scripts for new columns

Valid from Pega Version 7.1.4

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.
  Depending upon your database type (platform) and the size of your database, these scripts may require significant time and system resources to run.

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

Derby databases are no longer supported

Valid from Pega Version 7.1.8

Previously, an embedded Derby database could be used as a file system. This setup was configured by setting storage/class/<<filesystem>>/type to "embedded" in the prconfig file.

After upgrading, storage types that are specified as "embedded" now default to the local file system.

Custom database (DB) triggers are dropped during upgrade

Valid from Pega Version 7.1.8

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.

Configuration required for data operations on external schema when using a Postgres database

Valid from Pega Version 7.1.8

When you use the API for data operations on external schema in the Postgres database, you must update the prconfig.xml file. No other platform requires a prconfig.xml update.

To update the prconfig.xml file:

  1. Stop the server and add the following entry to the prconfig.xml file:
    env name="database/databases/postgres_ext/defaultSchema"
    value="externalschema"
    where postgres_ext is the external database that uses the external schema “externalschema”.
  2. Restart the server.

End of support for Netscape Plugin API in Google Chrome 45

Valid from Pega Version 7.1.8

Beginning with Chrome 45, which is expected to be available in September 2015, Google is ending support for browser plug-ins that rely on the Netscape Plugin API (NPAPI) architecture. These plug-ins include Microsoft Silverlight, Adobe Flash Player, and Java.

The Pega 7 Platform includes several optional features that use these plug-ins. For a detailed overview of these features, see Client-side technologies.

Existing operator IDs during upgrades and updates

Valid from Pega Version 7.2.2

Upgrades and updates are always performed in secured mode to help prevent unauthorized access to your system. In secured mode, the [email protected] operator ID is always overwritten, but other existing standard operator IDs are not modified. New operator IDs are inserted in secured mode. For more information, see the Deployment Guide for your environment.

Pega File Listener process changes

Valid from Pega Version 7.2.2

Beginning with Pega 7.2.2, File Listener processes files in a different way:

  • File movement in directories – Previously, files were processed from the Work directory. In Pega 7.2.2, files are processed from the source location. Files move to the Work directory only if the initial processing fails and Recovery is disabled.
  • New file processing – Previously, File Listener would process all files in the source location, even if the files were added during the processing. In Pega 7.2.2, files added to the source location during processing are read the next time the File Listener starts.

For more information, see File Listener data instances.

Functionality of the pyInvokeRESTConnector rule and the pxDeferenceEndpoint rule moved to core engine

Valid from Pega Version 7.2.2

The functionality of the pyInvokeRESTConnector rule and the pxDeferenceEndpoint rule has been moved into the core engine code of the Pega 7 Platform. This change provides more consistent behavior, reduces maintenance, and reduces the risk of regression issues. As a result, you can no longer customize these rules, and upgrading the Pega 7 Platform requires special considerations if you previously customized these rules.

For more information, see Upgrading with customized pyInvokeRESTConnector and pxDeferenceEndpoint rules.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us