SR-A1273 · Issue 197681
PRPCTask is now tenantized
Resolved in Pega Version 7.1.9
On a multi-tenant environment with HTTP event, it was not possible to see the options for warm\blind transfer with interaction from a tenant layer. This was an issue with the task taking the user ID information but not taking the tenant information, so the acceptance of the interaction on the portal was not getting delivered to the desktop. To correct this, PRPCTask is now tenantized.
SR-A3149 · Issue 209034
Added handling for Oracle functional indexes of length '1'
Resolved in Pega Version 7.1.9
The SchemaChangeUtils class was throwing a java.lang.StringIndexOutOfBoundsException when an administrator attempted to view the "Missing PRPC Shipped Schema" section of the "PRPC Schema Report" page after upgrade (System -> Release -> Upgrade -> PRPC Schema Report). This appeared to lead to the message "Can not render section" in the PRPC schema report UI. The StringIndexOutOfBoundsException was due to Oracle functional indexes of length '1' which were not handled while doing a substring in schemaChangeUtils class: this handling has now been added.
SR-A34 · Issue 204505
Pega Lookup JSP tag correctly retrieves Chinese characters
Resolved in Pega Version 7.1.9
When the pega:lookup JSP tag did a field value lookup on pyCaption to retrieve the field value consistent with the locale, any Chinese characters embedded in the HTML pages used to generate the PDF rendered correctly but '?????' appeared in the PDF content instead of the Chinese characters configured in the Field-Value pair. This was caused by an issue in the code which caused the system to incorrectly identify NVARCHAR columns as being VARCHAR columns. This has been fixed., and the encoding for TestDatabaseNew has also been set to be UTF-8 to ensure the Non-ASCII characters in the tests are handled properly in all workspaces.
SR-A3428 · Issue 212424
Modified ClassName pass method for external DBs
Resolved in Pega Version 7.1.9
When DB2 is used as external DB (external table has a date column) and PRPC is hosted on a DB other than DB2, performing an obj-save into an external DB2 database failed with an SQL error. This issue occurred when a class was mapped to a table in an external DB which was not same as Pega hosting DB. In class PageDatabaseMapperImpl.java , function getDatabaseTypeFromEngine is used to check the database type when column type is Date, but the function was using a hardcoded value of class to determine the database type. This has been changed to pass className as parameter and use it to determine database type.
SR-A3744 · Issue 209253
Resolved Vtable NPE during engine start
Resolved in Pega Version 7.1.9
If a Rule-Access-When was defined on the class Data-Admin-System-Settings, search was initialized before the VTable is initialized. While initializing search, a DASS was set and a save operation was performed on the DASS which then tried to perform a security check and attempted to retrieve the Rule-Access-When from the unpopulated VTable cache. This led to an NPE. To resolve this, changes have been made so that search will be initialized after Vtable is populated.
SR-A940 · Issue 205402
Locking issue resolved for importing PUI jars
Resolved in Pega Version 7.1.9
Errors were being generated when importing PUI framework jars. This was an issue where the savepoints created in Saver.executeUpdate needed to be explicitly released on PostgreSQL to avoid locks from accumulating for each of the nested transactions, and the problem has been resolved.
SR-A990 · Issue 205075
Post-upgrade deferred list mapping reference inserted for new classes
Resolved in Pega Version 7.1.9
After migrating, the processing of the deferredlist while performing an updatestatus operation generated an exception from pzMapCases. This was caused by a class mapping issue where the new classes (InsertRuleSummary, UpdateRuleSummary, DeleteRuleSummary) added in DeferredOperationsImpl did not have interfaces in DeferredOperation. This has been corrected.
SR-D37317 · Issue 512553
Run Ruleset Cleanup defaults to true
Resolved in Pega Version 8.2.6
After upgrade, the rule categories and rules were not showing correctly in the App view of the Dev Portal. Many warning messages were also logged related to the Decisioning DM Sample application. This was traced to the rules cleanup script not running properly. While there was a workaround of applying the ruleset cleanup scripts manually after removing the queries that reference the pr_engineclasses table, the cleanup will now be set to run by default (run.ruleset.cleanup=true). In addition, the logic to determine which RuleSets to include has been simplified and most of the pr4_rule_vw deletions have been combined.
SR-D38318 · Issue 519710
Data pages explicitly cleared after QP use
Resolved in Pega Version 8.2.6
The Util Node was showing as Offline in the Search Landing Page, and when Jobs were submitted for execution from other Nodes the message "Detected active run with unreachable nodes" was logged. The util node, configured as a backgroundprocessing node, was running QPs; the queue size for custom QPs is 500 messages /queue items per minute, but investigation showed the requestor level and thread level data pages corresponding to the QP activities were not being cleared after use. This led to high heap memory issues that made the node unreachable, and has been resolved by adding code to explicitly remove the data pages when processing has finished.
SR-D48396 · Issue 520423
Hazelcast upgraded to resolve node startup issue
Resolved in Pega Version 8.2.6
Post data upgrade, the ADM tier failed to start and the error "java.lang.IllegalStateException: Node failed to start!" appeared. This was traced to a dormant bug in Hazelcast 3.11 that caused starting nodes to fail when the Hazelcast master node was shutting down, which was exposed by recent Pega changes made to enable parallel restarts of nodes in Cloud environments. Hazelcast delivered a fix for the parallel restart problem and the hotfixed jar has been merged into the platform. In addition, previous logic for loading Admin Studio waited 30 seconds before timing out when fetching information for each node. This caused issues with large clusters and Admin Studio not loading. The logic has been updated in the Admin Studio UI to load the page despite delays/issues waiting for nodes to respond to the gathering of cluster data, and the algorithm to detect remote-call timeout has been updated and is applicable to batch operation.