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.

Add the security checklist to applications created before 7.3.1

Valid from Pega Version 7.3.1

The security checklist is now automatically added to applications. You can manually add the security checklist to applications that were created in earlier versions.

You can improve the security of your application by completing the tasks on the checklist.

The following task reflects the procedure on how to manually add the security checklists to Designer Studio prior to 7.3.1:

  1. In the header of Designer Studio, click the name of the application, and then click Definition.
  2. Click the Documentation tab.
  3. In the Application guides section, click Add guide.
  4. In the Application guide& field, enter pxApplicationSecurityChecklist.
  5. Click the Configure icon in the Available in column and select the portals (App Studio and Dev Studio) that you want to add the security checklist to.
  6. Click Save.

Data schema error on z/OS split schema upgrades from versions before Pega 7.1.8

Valid from Pega Version 4.1

When upgrading to a split schema on Pega 7.x with IBM DB2 for z/OS, you see an error during the data schema upgrade when the system tries to drop the PRPC_Updatescache procedure. Because triggers on rules tables use PRPC_Updatescache, you must use the ZOSDisableTriggerScripts to disable these triggers before you update the data schema.

  1. Follow the instructions in the Pega 7 Platform Upgrade Guide to upgrade the rules schema, but stop immediately before you upgrade the data schema with the upgrade.bat or upgrade.sh script. The Pega 7 Platform Upgrade Guide is on the Support > Deployment Guides page.
  2. Copy the contents of the <distribution>\ResourceKit\ZOSDisableTriggerScripts directory into the <distribution>\scripts\ directory.
  3. Run fixZosTriggers.bat or fixZosTriggers.sh with the following arguments:
    --action preupgrade
    --dataschema <data schema name>
    --oldrulesschema <old rules schema name. If you are upgrading from a single-schema system, this is the data schema name.>
    --newrulesschema <new rules schema name>
    --automaticddl <Optional. Set to true to automatically apply the disable trigger SQL scripts.>

    For example:
    fixZosTriggers --action preupgrade --dataschema pegadata --oldrulesschema pegarules --newrulesschema newrules --automaticddl false

  4. If you did not set --automaticddl to true in the previous step, run the <distribution>\schema/disable.sql script to manually disable the trigger SQL scripts.
  5. Run the data schema upgrade as described in the Pega 7 Platform Upgrade Guide.

Rules Assembly cache is deprecated

Valid from Pega Version 7.3.1

Rules Assembly (RA) cache and custom settings for its corresponding fua/assemblyCacheModeprconfig.xml file setting are deprecated because they are obsolete. A warning is logged at startup if a custom (non-default) value is specified for fua/assemblyCacheMode in the prconfig.xml file. The functional behavior of the system is not affected.

Use of PegaRULES_Extract_Marker.txt to delete cache is deprecated

Valid from Pega Version 7.3.1

The PegaRULES_Extract_Marker.txt file is deprecated. The system uses the presence or absence of the PegaRULES_Extract_Market.txt file to determine at startup whether to delete the static content, service export, and lookup list file system-based caches. In the rare situation that you need to delete these caches manually, use the System Management Application (SMA) ETier Static Content Management page. Using SMA does not require restarting the node.

Behavior changes when reporting on descendant classes

Valid from Pega Version 7.3.1

Report Definitions that use the Report on descendant class instances option with the Include all descendant classes option apply only to the Applies to Class. Join classes are not included as they were in previous Pega® Platform versions. The following example shows what happens for each possible scenario for Report on descendant class instances when the report is defined on ClassA with a class join with Work-.

  • If Report on descendant class instances is disabled, the report runs against ClassA and the join happens with Work-. The behavior is the same in Pega 7.3.1 as it is in previous Pega Platform versions.
  • If Report on descendant class instances is enabled, and Include single implementation class is selected, the report runs against ClassA and the join happens with the MySampleClass implementation class. The behavior is the same in Pega 7.3.1 as it is in previous Pega Platform versions.
  • If Report on descendant class instances is enabled, and Include all descendant classes is selected, the report runs against ClassA and its descendants and the join happens with Work-. In previous Pega Platform versions, the join happened with the MySampleClass implementation class.

Changes in JSON results when checking the health of your system

Valid from Pega Version 8.2

Beginning with Pega Platform™ 8.2, the JSON results that are returned when you ping a Pega Platform instance have changed. JSON results now include node type and health information, including test name, status, state, and node ID. The following samples show JSON results from versions before 8.2 and as of 8.2.

JSON results for pre-Pega Platform 8.2:

{ "duration":"3954.448601", "count":"0" }

JSON results for Pega Platform 8.2 and later:

{"node_type":["WebUser"],"health":[{"last_reported_time":"2019-02-14T16:10:49.589Z","test_name":"Sample-Stream-Check","status":"success"}],"state":"healthy","node_id":"10.10.10_samplenode"}.

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