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.

Required Oracle optimization parameter

Valid from Pega Version 7.1.3

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

Valid from Pega Version 7.1.3

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

Valid from Pega Version 7.1.3

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

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.

Decision Data Store data sets can be used only on DNodes

Valid from Pega Version 7.1.8

Data flows that contain Decision Data Store data sets as the primary or secondary source must be created and executed only on DNodes.

Data flows are not restarted automatically after application server restart

Valid from Pega Version 7.1.8

When you restart the application server or the Pega 7 server, you stop the execution of your data flows. The interrupted batch and real-time runs are marked as Failed

Recommendation:

  • Go to the Designer StudioDecisioning > Decisions > Data Flows > Batch processing tab and start the failed batch runs.
  • Go to the Designer StudioDecisioning > Decisions > Data Flows > Real-time processing tab and activate the failed real-time runs.

 

Value list and value group properties are not supported inside data flows

Valid from Pega Version 7.1.8

Value list and value group properties are not supported inside data flows, and you need to instead use other property types.

See the Pega 7 developer help to check all available property types.

Data flow preview size is fixed to 10

Valid from Pega Version 7.1.8

The Preview option for each shape in data flows returns the first 10 records. This value is fixed and currently cannot be changed.

Data Flow transformation shapes cannot be used in combination with the Compose or Merge shapes

Valid from Pega Version 7.1.8

When you reference another data flow from a data flow that contains the Compose or Merge shape, the referenced data flow cannot contain transformation shapes (EventStrategy, Decision strategy, Convert).

Data flow validation does not currently prevent you from designing a data flow that goes against this design pattern. Make sure that your data flows follow this design pattern by checking the referenced and referencing data flows.

 

Data flow destination is resolved at assembly time

Valid from Pega Version 7.1.8

Data flow execution always uses the design-time destination data sets or destination data flows, regardless of the input records at run time.

Example:

You create a data flow and set the destination to a specific data set. In the data flow, you use a strategy that produces some results. Regardless of these results, the execution of your data flow always uses the destination data set that you specified when you designed the data flow.    

The same applies when you set the destination to a data flow.

 

 

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