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.

System Management

Valid from Pega Version 7.1.3

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.

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.

Upgrade changes system name

Valid from Pega Version 7.1.1

As of Pega 7.1.7, the following renaming behavior no longer occurs.

The upgrade process renames your system to “PRPC” and modifies any custom requestor rules in your application to use this name. After the upgrade completes, you must apply these changes to revert your system:

  1. Identify all custom requestor rules (browser, batch, app, portal) with access groups that point to prior versions of PRPC.
  2. Open the relevant access groups (for example, PRPC:Unauthenticated and PRPC:Agents) and update the name and version fields to point to the current PegaRULES application.
  3. Reset your system name to its original value. You can set the Dynamic System Setting prconfig/identification/systemName/default or use the Designer Studio > System > Settings > System Name landing page.
  4. Restart the system.

Required DB2 settings

Valid from Pega Version 7.1.1

For customers using the DB2 Version 4 drivers (“db2jcc4.jar”), it is necessary to set the custom connection property useJDBC4ColumnNameAndLabelSemantics to “false”.   

For customers using DB2 with WebSphere, the useJDBC4ColumnNameAndLabelSemantics property in the DB2 data source needs to be changed from a Boolean to an Integer and set to "2". 

EAR support for JBoss EAP 6

Valid from Pega Version 7.1.5

PRPC deployment in JBoss EAP 6 as an EAR archive is now supported. 

If you need to deploy the JBoss EAR file, go to My Support Portal and submit a Support Request. GCS can assist you with the procedure.

Service levels for case stages

Valid from Pega Version 7.1.5

Service levels are available for stages in stage-based case management applications.

The service level starts when a case enters a stage and stops when it exits. The service level is defined in the Service level for stage field on the "Stage Configuration" dialog, which is accessed on the Case Designer Stages and Processes tab.

108951_stagesla.png

Alternatively, you can add a stage service level on the case type record's Stages tab.

Customize your starting flow list

Valid from Pega Version 7.1.5

The Designer Studio Create menu now populates the list of starting flows by referencing the case types that you select (including case types in Create Menu checkbox) on the application form's Cases and Data tab. The order of the case types on the tab dictates the order of flows that appear on the menu.

108956_CreateCaseMenu.png

Previously, the Create menu displayed all starting flows in the current workpool. This new feature enables you to control which flows appear on the menu.

You can change the sort order by customizing the extension activity pySortStartingFlows. For example, you can sort the flows by their short descriptions.

Where-Am-I? includes stage and step progress

Valid from Pega Version 7.1.5

In stage-based case management applications, the Where-Am-I? display includes a read-only presentation of primary stage and step shapes. Green checkmarks indicate completed steps. A red arrow indicates the current step.

108961_whereami_0.png

Stop active processes on stage exit

Valid from Pega Version 7.1.5

The Change Stage smart shape provides a "Remove processes on exit stage" option that stops all active processes in a stage when a case leaves it. The system removes the stage's open assignments from user forms.

Standard page lists for attachments

Valid from Pega Version 7.1.5

The following new standard page lists allow you to easily reference attachments in your designs:

  • pyAttachments — Holds a list of attachments of the current case.
  • pyAttachmentCategoriesList — Holds a list of attachment categories of the current case. This property can be used to fetch the attachment information by category (pyAttachmentsByCategory).
  • pyAttachmentsByCategory — Holds a list of attachments for the category set in the pyAttachmentCategory property in the current case.

When a user or system adds an attachment, the system automatically associates the page lists with the case, and populates them when the properties are referred to.

Creating an attachment category in a case type record automatically creates a property reference. See Redesigned Attachment Categories tab on Case Type record.

In addition, you validate the existence of an attachment by referencing the new function alias pxIsAttachmentOfCategoryInCase in a validate record. For example, you can use the properties and a validate record for building when logic that makes it necessary for a user to attach a document of category "SECCompliance" before the case can enter a stage.

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