Published Release Notes

Required Oracle optimization parameter

To optimize performance, set the Oracle parameter optimizer_index_cost_adj to a value between 20 and 25. If this value is not set, the system can run exceedingly slowly, potentially blocking users from login.

Split schema upgrade instructions missing properties

If you upgraded from 5.x, 6.x, or 7.x using the instructions in previous versions of the upgrade guide, you may have neglected to set the properties below in your migrateSystem.properties file when you migrated your upgraded schema to the source system:

pega.rules.objects.generate=true

pega.rules.objects.apply=true

If these properties were not set during an upgrade that splits the schema, your environment does not have the indexes, triggers, and primary keys on the rules tables.

To check for this issue, see if the pr4_base and pr4_rule rules tables in your existing rules schema are missing primary keys. If they are, use the SQL scripts in the ResourceKit\MigrationRecoveryScripts directory of the release to cleanup duplicate rules that were created due to this issue. Follow the steps below to run the scripts.

To run the scripts on Microsoft SQL, Oracle, or PostgreSLQ

1. Take down any app servers using the affected schema.
2. Backup your database.
3. Replace all instances of @RULES_SCHEMA in <database>_cleanDups.sql with the name of the schema that contains the pr4_base table.
4. Run the <database>_cleanDups.sql script on the database with vendor tools (sqlPlus, SQL Server Management Studio, etc).
5. Replace all instances of @RULES_SCHEMA in <database>_fix_vw_table.sql with the name of the schema that contains the pr4_base table.
6. Run the <database>_fix_vw_table.sql script on the database with vendor tools (sqlPlus, SQL Server Management Studio, etc).
7. Generate and apply the ddl using the command line generateDDL command. Check the installation guide for your database or the upgrade guide for details about how to use the generateDDL command line script.
8. Rebuild the indexes for the tables in your rules schema using vendor tools. This is necessary so that your system runs at an optimum speed.
9. Optionally upgrade to the latest release, at this point your database is ready to be upgraded or used depending on your needs.

To run the scripts on DB2 for LUW or z/OS

1. Take down any app servers using the affected schema.
2. Backup your database.
3. Run the <database>_cleanDups.sql script on the database with vendor tools (UDB CLP, Data Studio, etc) to create the CLEANSE_RULES_DUPS stored procedure.
4. Run the query Call CLEANSE_RULES_DUPS(‘<rulesSchema>’); where <rulesSchema> is the name of schema that contains the pr4_base table.
5. After the previous step is complete drop the CLEANSE_RULES_DUPS procedure.
6. Replace all instances of @RULES_SCHEMA in <database>_fix_vw_table.sql with the name of the schema that contains the pr4_base table.
7. Run the <database>_fix_vw_table.sql script on the database with vendor tools (UDB CLP, Data Studio, etc).
8. Generate and apply the ddl using the command line generateDDL command. Check the installation guide for your database or the upgrade guide for details about how to use the generateDDL command line script.
9. Rebuild the indexes for the tables in your rules schema using vendor tools. This is necessary so that your system runs at an optimum speed.
10. Optionally upgrade to the latest release. At this point your database is ready to be upgraded or used depending on your needs.

Synchronized database and application server settings

Configure your database and application server to use the same time zone and character encoding to avoid conflicts.

System Management

The PRPC installer has been enhanced to handle additional error conditions related to partial installs and duplicate keys; additionally, the hotfix rollback feature has been improved, and the Rulebase compare tool now supports HTTP(S) environments.

• Rollback feature has been enhanced.
• RuleBase Compare will work for secure (HTTPS) environments as well as  non-secure (HTTP) environments.
• Install will gracefully handle the presence of a duplicate key during import.
• When install fails, system will set tables back to original state.
• Remote MBean methods will now work on multi-servant load-balancing systems.
• Enhancements were made to harnesses in Split Schema systems.

Improved security after hiding SQL values

In Pega Platform™ version 8.6, the default value of the showSQLInList dynamic system setting changes to FALSE, which suppresses the visibility of the SQL values in the Clipboard tool. With this setting disabled, when you run a report definition the clipboard does not display sensitive values in the pxSQLStatementPre and pxSQLStatementPost properties, which makes your system less vulnerable. If you want to display the values, in the .prconfig file, set the prconfig/security/showSQLInListPage/default to TRUE.

Additional connection pool parameters for JDBC URL external databases

For improved external JDBC URL database connection performance, Pega Platform™ now supports multiple Hikari connection pool parameters directly in the Data-Admin-DB-Name rule. Previously, Pega Platform supported a limited number of connection pool parameters to optimize your database connection using dynamic system settings (DSS). Now you can optimize your JDBC URL connection pool sizing to meet your traffic requirements through additional parameters without switching rules. Additional parameters include client-request parameters to maximize the connectivity to your external databases.

For more information, see Creating and updating external database instances with JDBC URLs.

Upgrade impact

During an upgrade to Pega Infinity™ release 8.6 and later, clients who previously specified their JDBC URL connection parameters through dynamic system settings (DSS) or prconfig file must delete the corresponding DSS or prconfig elements immediately after upgrade. The old parameters that you previously specified through DSS or the prconfig file override the equivalent parameters that you specified in the JDBC URL rule after your upgrade.

For more information about deleting your previous DSS or prconfig elements, see Deleting dynamic system setting connection parameters and Deleting connection parameters in the prconfig file.

Enhanced PEGA0104 alert

The PEGA0104 alert now includes the thread pool size, a list of activities that are waiting in the queue for a thread to become available, and details on how long it took to capture the thread dump.  By default, the alert also includes the thread dump.  You can disable the inclusion of the thread dump by changing the related configuration option. 

For more information, see PEGA0104 alert: Background tasks have exceeded a threshold time when attempting to acquire a thread from pool or executor.

New alert for job scheduler activity that exceeds a time threshold

Pega Platform™ now saves the PEGA0130 alert in the performance alert log at the time that a scheduled job exceeds the configured threshold value. To identify performance issues with long-running processes, you can monitor the log for the alert while the job scheduler runs.

The alert is enabled by default. You can change the default threshold value or disable the alert in dynamic system settings.

For more information, see PEGA0130 alert: Current Job Scheduler run is taking too long.

Data model inheritance does not depend on ruleset context

Search and Reporting Service (SRS) in Pega Platform™ 8.6 now provides an improved method of synchronizing data model by distinct users. In applications built on earlier versions of Pega Platform, some users might encounter difficulties in indexing data. Now, the data model that the system sends to SRS does not depend on access privileges. With this enhancement, each user of your application is eligible to synchronize data.