Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

INC-185362 · Issue 668826

Keystore update properly revises the cache

Resolved in Pega Version 8.7

A keystore updated with the latest certificate was not getting reflected in the runtime and the old certificate was getting picked. In a multi-node environment when the new JKS is uploaded in one node, the changes are expected to be communicated to other nodes so that the cache can be cleaned up. In this case, investigation showed that the keystore label was in uppercase and the cache entry was not correctly removed. This has been resolved by adding an update that will convert the cache key to lowercase and maintain uniformity to ensure proper cleanup.

SR-C79523 · Issue 421039

Updated the documentation for enabling debug logging during upgrades

Resolved in Pega Version 8.3

The documentation regarding enabling debug logging during upgrades has been updated to reflect the following information: To enable debug logging during installs, upgrades or prpcUtils invocations: The template logging configuration for installs, upgrades and prpcUtils is located within the scripts/config directory of the Pega Platform distribution. To change what gets logged, modify the prlog4j2.xml file (refer to https://logging.apache.org/log4j/2.x/manual/configuration.html#XML). Some of the utilities involved in the install and upgrade processes use java logging. To impact what is logged by these tools, modify the deploylogging.properties file in the same directory.

SR-C84384 · Issue 430962

Logoff control for Sales Automation case worker portal updated to clear states

Resolved in Pega Version 8.3

After logging in to the Sales Automation case worker portal and clicking a menu item other than dashboard, the link was properly highlighted in the navigation menu and the appropriate data was loaded in the harness. However, after logging out of the application and logging again as the same user, the portal opened to the dashboard page and the previously clicked link was highlighted instead of the dashboard link in the left navigation menu. While it was possible to reset the menu state by closing the browser and starting a new session, the issue has been resolved by updating the logoff control for this portal to use the general system control_logoff which clears states on exit.

SR-D5196 · Issue 445416

Hardcoded prweb reference removed from the REST connector to enhance flexibility

Resolved in Pega Version 8.3

The DASS for pegarobotics/RobotManagerHostDomain allows specifying the instance where Robot Manager is hosted. Previously, connect-REST pzInvokeRoboticAutomation contained a reference to the resource path {RobotManagerHostDomain}/prweb/PRRestService/robotics/v1/automations which forced the use of prweb. In order to add flexibility, the hardcoded prweb reference has been removed from the REST connector resource path, and the pegarobotics/RobotManagerHostDomain) DASS's default value has been updated to include 'prweb' in it. Local sites should update DASS accordingly to point to an updated URL with prweb if needed.

SR-D8390 · Issue 488002

Handling added for runtime exception on upgrade due to inaccessible external schema mapping

Resolved in Pega Version 8.3

If a system used external schema mapping, attempts to upgrade were failing with the error "Caused by: com.pega.pegarules.pub.database.ConfigurationException: Unable to obtain data source "java:comp/env/jdbc/PegaRULES", as it is undefined". This was traced to configuring external DADNs which were not accessible from the server where the upgrade was being run: an upgrade will fail if it cannot connect to an external datasource even if no changes need to be made to that datasource. However, because a PRRuntimeException was unexpectedly being thrown instead of a Database Exception, the exception was not properly caught and handled. This has been corrected.

INC-195354 · Issue 682183

Handling updated for UpgradeBeforeOpening

Resolved in Pega Version 8.7

After update, an email case paused for 1 minute with a wait shape and then resumed by a ServiceLevelEvents agent seemed to lose the context (class) of the case and went into the broken processes queue with the error "Unable to open an instance using the given inputs: pxObjClass = "Work-Channel-Triage"". This was traced to an incorrect class applied by the activity OpenAndLockWork which assumed that "Work-Channel-Triage" was the preferred class and passed in the case ID as a parameter. To resolve this, pzUpgradeBeforeOpening has been updated such that it will migrate a case only if it has "WORK-CHANNEL-TRIAGE" in the work object inskey.

SR-A102237 · Issue 271876

Unmapped columns from an external table skipped in DDL query generation.

Resolved in Pega Version 7.3

The OBJ-SAVE method was generating a query in which unmapped columns were also getting updated. As these columns were not mapped, DB columns were being updated with the value NULL. This was due to the Obj-Save function always saving the entire object, causing an issue when only part of a table is mapped to a class. To correct this, new prconfig and DASS settings have been added to exclude unmapped columns of an external table as part of DDL query generation.

SR-A87830 · Issue 258083

PD4ML JAR updated

Resolved in Pega Version 7.3

Metadata dates in a PDF generated with PD4ML are expected to follow ISO 8601 format "YYYY-MM-DDThh:mm:ss+##:##", with "+##:##" being the time zone adjustment based on UTC, but when the time zone was given as UTC (or a time zone with zero adjustment), PD4ML was setting the date as "YYYY-MM-DDThh:mm:ssZ00:00". This consequently generated errors with various PDF/A tools. To resolve this, the PD4ml jar has been updated.

SR-A87830 · Issue 258092

PD4ML JAR updated

Resolved in Pega Version 7.3

Metadata dates in a PDF generated with PD4ML are expected to follow ISO 8601 format "YYYY-MM-DDThh:mm:ss+##:##", with "+##:##" being the time zone adjustment based on UTC, but when the time zone was given as UTC (or a time zone with zero adjustment), PD4ML was setting the date as "YYYY-MM-DDThh:mm:ssZ00:00". This consequently generated errors with various PDF/A tools. To resolve this, the PD4ml jar has been updated.

SR-A87830 · Issue 259106

PD4ML JAR updated

Resolved in Pega Version 7.3

Metadata dates in a PDF generated with PD4ML are expected to follow ISO 8601 format "YYYY-MM-DDThh:mm:ss+##:##", with "+##:##" being the time zone adjustment based on UTC, but when the time zone was given as UTC (or a time zone with zero adjustment), PD4ML was setting the date as "YYYY-MM-DDThh:mm:ssZ00:00". This consequently generated errors with various PDF/A tools. To resolve this, the PD4ml jar has been updated.

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