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-150633 · Issue 614512

Optimizing helper class enhanced to handle external databases

Resolved in Pega Version 8.4.4

Running a BIX extract that included a manifest for a target database was resulting in a null pointer exception for the manifest extraction. Attempting to generate the DDL for the manifest table also failed. This was traced to an issue with the helper class using a hardcoded default database for forming the queries, causing it to ignore the database config/DADN/prconfig for the Oracle database and form a query using the PegaRules' database credentials. This only occurred when trying to do external database operations on a different database platform; Oracle PegaRules worked as expected with an Oracle external database and Postgres Pegarules worked with a Postgres external database, but mixing Postgres PegaRules and an Oracle external database would result in the Null pointer exception. To resolve this, the helper class has been enhanced to work with external databases by passing the database name as a parameter so it will properly calculate the query based on the type of target. An error in the name of the class has also been corrected, and is now available as PerformanceHelper rather than the previous "PerformaneHelper".

INC-150861 · Issue 611864

Optimizing helper class enhanced to handle external databases

Resolved in Pega Version 8.4.4

Running a BIX extract that included a manifest for a target database was resulting in a null pointer exception for the manifest extraction. Attempting to generate the DDL for the manifest table also failed. This was traced to an issue with the helper class using a hardcoded default database for forming the queries, causing it to ignore the database config/DADN/prconfig for the Oracle database and form a query using the PegaRules' database credentials. This only occurred when trying to do external database operations on a different database platform; Oracle PegaRules worked as expected with an Oracle external database and Postgres Pegarules worked with a Postgres external database, but mixing Postgres PegaRules and an Oracle external database would result in the Null pointer exception. To resolve this, the helper class has been enhanced to work with external databases by passing the database name as a parameter so it will properly calculate the query based on the type of target. An error in the name of the class has also been corrected, and is now available as PerformanceHelper rather than the previous "PerformaneHelper".

INC-153223 · Issue 613703

DSS added to set Cassandra query page size limit

Resolved in Pega Version 8.4.4

When a site with a large number of nodes captured responses to the commit log, it was possible for nodes run out of heap space and cause system instability. This was due to the Cassandra query not having a specified page size, so the cluster-wide default setting of 5000 created an issue for large sites which could have over 150 nodes capturing responses. This has been resolved by specifying the page size on the Cassandra query that used to read responses from the commit log. This value will be set dynamically with a DSS to not read more than n responses from all shards combined in a single batch.

INC-207524 · Issue 714707

Handling added for modal flow to resolve unexpected submit window closure

Resolved in Pega Version 8.8

After creating a child Task and submitting the TaskCreation flow action, a validation error was seen. Clicking on the Submit button again caused the modal TaskCreation window to close. Investigation showed that the WorkLock activity was executed as desired on the first click on submit, but for the second submit the WorkLock activity called Obj-Refresh-And-Lock and the page was refreshed, the work object lock was released, and the error was no longer seen. To resolve this, an update has been made to the WorkLock activity to use a new when rule 'pyIsModalFlowTemporary' so that Obj-Refresh-And-Lock is not called twice. This change has also been added to pzRunFlow.

INC-234543 · Issue 743003

Parameter value with carriage return evaluated correctly

Resolved in Pega Version 8.8

If a text area control had multiple lines entered in it and the same text area was passed as a parameter to a Data Transform executed at the launch of a read-only harness, the value in the text area was - " #~pyworkpage.propertyname". If the text area had just a single line without any enters/multiple lines, then it worked as expected. This was traced to the handling in pzpega_ui_events and has been resolved by escaping the newline and carriage return characters. An additional issue found when using multiselect in the form was traced to the correctActionArgs function which was generating the replacedtoken "//string//" for one of the property subjectareadetails, and this has been corrected.

SR-C69441 · Issue 415967

Copy/Merge Wizard ProcessRequest will create new rule instead of modifying the old

Resolved in Pega Version 8.1.3

When using the Copy/Merge wizard to move the rules from one ruleset to another with the "Delete Source RuleSet(s) upon completion of merge" option set to YES, the SECTION rules were still being referred even though the target ruleset was not part of the application stack. In the Tracer, it could be seen that the rule appears in the source ruleset version even though the ruleset did not exist, and attempting to open the rule from tracer or from Live UI caused it to open in the Target ruleset version (which was not part of application). This was traced to the system not updating the cache, leading to RULE-OBJ-ACTIVITY PEGAACCEL-MANAGEMENT-REFACTOR-RULESET PROCESSREQUEST applying an incorrect strategy when updating the rule and rulesets. Because the original rule was never invalidated, its shortcut and entry remained and any references to it weren't updated. To correct this issue in a comprehensive way, the ProcessRequest has been modified to create a new rule instead of modifying the old rule, and pxCreateDateTime will be added to the rulepage before saving.

INC-217904 · Issue 730432

New prconfigs added to handle lob closed error

Resolved in Pega Version 8.8

BIX extraction was encountering the SQL error "Invalid operation: Lob is closed" while reading the BLOB, but the rest of the records were able to be extracted. This was traced to previous work done to resolve an issue where Oracle temporary space used to write the LOB was not freed up after writing records to Log-Service-File when using OJDBC8 or OJDBC10 versions. This change caused an issue for DB2 where the freed BLOB was still trying to be extracted. To address this, new prconfig settings have been introduced to control freeing BLOB memory. If the error is seen regarding the lob being closed, add and disable these settings (set value as false) in the pronfig.xml file. DATABASE_MANAGEMENT_FREELOB: settingName: database/management/freeLOB description: If this flag is set to false, it controls the free memory calls defaultValue: true DATABASE_MANAGEMENT_FREEPAGEDBMAPPERLOB: settingName: database/management/freePageDBMapperLOB description: If this flag is set to false, it controls the free memory calls. defaultValue: true Following this change, restart the server.

INC-218802 · Issue 736911

New prconfigs added to handle lob closed error

Resolved in Pega Version 8.8

BIX extraction was encountering the SQL error "Invalid operation: Lob is closed" while reading the BLOB, but the rest of the records were able to be extracted. This was traced to previous work done to resolve an issue where Oracle temporary space used to write the LOB was not freed up after writing records to Log-Service-File when using OJDBC8 or OJDBC10 versions. This change caused an issue for DB2 where the freed BLOB was still trying to be extracted. To address this, new prconfig settings have been introduced to control freeing BLOB memory. If the error is seen regarding the lob being closed, add and disable these settings (set value as false) in the pronfig.xml file. DATABASE_MANAGEMENT_FREELOB: settingName: database/management/freeLOB description: If this flag is set to false, it controls the free memory calls defaultValue: true DATABASE_MANAGEMENT_FREEPAGEDBMAPPERLOB: settingName: database/management/freePageDBMapperLOB description: If this flag is set to false, it controls the free memory calls. defaultValue: true Following this change, restart the server.

INC-220251 · Issue 732073

New prconfigs added to handle lob closed error

Resolved in Pega Version 8.8

BIX extraction was encountering the SQL error "Invalid operation: Lob is closed" while reading the BLOB, but the rest of the records were able to be extracted. This was traced to previous work done to resolve an issue where Oracle temporary space used to write the LOB was not freed up after writing records to Log-Service-File when using OJDBC8 or OJDBC10 versions. This change caused an issue for DB2 where the freed BLOB was still trying to be extracted. To address this, new prconfig settings have been introduced to control freeing BLOB memory. If the error is seen regarding the lob being closed, add and disable these settings (set value as false) in the pronfig.xml file. DATABASE_MANAGEMENT_FREELOB: settingName: database/management/freeLOB description: If this flag is set to false, it controls the free memory calls defaultValue: true DATABASE_MANAGEMENT_FREEPAGEDBMAPPERLOB: settingName: database/management/freePageDBMapperLOB description: If this flag is set to false, it controls the free memory calls. defaultValue: true Following this change, restart the server.

INC-136563 · Issue 607420

Tenant Switching updated

Resolved in Pega Version 8.4.4

When working on new “tenant switching” implementations in a multi-tenant environment, the API itself seemed to be working as expected (case details from another tenant were shown correctly in review mode), but clicking on the assignment unexpectedly opened the case in a new window that contained the same review view of the case rather than the perform view. Clicking the assignment link again caused yet another review window to open with the same issue, over and over. This has been resolved by adding a UI-side update to send the requests on proper sub-domain URL instead of using the parent domain, and by ensuring the document threads are properly deleted for multitenant usecases.

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