INC-141579 · Issue 591852
Enhancement added for node heartbeat recovery process
Resolved in Pega Version 8.3.5
Nodes were not showing up in the admin portal even though they were up and running and could be seen in the pr_sys_statusnodes table. The exception "An exception was encountered while invoking the cluster membership listener callback" was seen. All nodes became visible again after multiple restarts. The root cause was traced back to a temporary database connectivity problem. The database itself was fine according to database monitoring reports, but a network problem, a slow database query, or another issue prevented Pega from establishing a connection for more than a minute. An enhancement has been made to resolve this: if a node becomes unhealthy due to the service registry missing due to a failed heartbeat, the heartbeat will try to recover after 60 seconds and keep trying every 30 seconds until it succeeds.
INC-142674 · Issue 594496
Enhancement added for node heartbeat recovery process
Resolved in Pega Version 8.3.5
Nodes were not showing up in the admin portal even though they were up and running and could be seen in the pr_sys_statusnodes table. The exception "An exception was encountered while invoking the cluster membership listener callback" was seen. All nodes became visible again after multiple restarts. The root cause was traced back to a temporary database connectivity problem. The database itself was fine according to database monitoring reports, but a network problem, a slow database query, or another issue prevented Pega from establishing a connection for more than a minute. An enhancement has been made to resolve this: if a node becomes unhealthy due to the service registry missing due to a failed heartbeat, the heartbeat will try to recover after 60 seconds and keep trying every 30 seconds until it succeeds.
INC-137255 · Issue 584910
Resolved Cassandra query read/write latency
Resolved in Pega Version 8.3.5
Read/write latency was seen when certain Cassandra queries were triggered by the system. This was traced to an unusual case where a flush was not done for an exceptionally long time period, and has been resolved.
INC-128880 · Issue 592817
Handling added for angle brackets in legacy Chart control
Resolved in Pega Version 8.3.5
When using Investigative Case Management, some report charts were not rendering correctly. This has been resolved by updating appendFormattedString in AbstractJsonDataGenerator.java to escape angled brackets (< and >) before appending the input.
INC-141322 · Issue 594513
Resolved drill up doubling the filter box
Resolved in Pega Version 8.3.5
When opening a report with a visual graph, clicking on one of the filtered options, leaving this box open (not submitting it) and then clicking on a bar in the visual graph of the report showed the contents of the graph, but then clicking on the report link to go back to the report overview caused a doubled filter box to be displayed. The report would then have to be reopened before being able to continue. The problem was that the value of .pyUI.pyConfigSecToShow was still set to "filter" after the drill down. When the drill back up happened, the report was trying to show the filter configuration section from before but the context was no longer available and it failed. This has been resolved by adding a call to pzCancelFilterLogicChanges in pzDrillUpReport to set the filters to the previous values and reset the value of pyConfigSecToShow.
INC-137317 · Issue 585404
Security improved for searches
Resolved in Pega Version 8.3.5
Authentication requirements have been added to activities associated with searching.
INC-139700 · Issue 591563
Shortcut works for copying reports into private rulesets
Resolved in Pega Version 8.3.5
Copying out of the box shortcuts to other categories in the Report Browser was failing with the error ".pyShortcutName: The rule name pyTimePerStage is a reserved name (starts with px, py, or pz) and is not created in a Pega- ruleset." This was caused by the system trying to create a new rule with a py prefix in a non pega- ruleset, which was a missed use case in the refactoring work of report actions to use the Record API. This has been corrected by moving the report ID generation logic from the activity pzValidateSaveAsInput to a new Rule-Utility-Function in the ReportingUtils library called pzGenerateUniqueRecordName so that it can also be used by pzCopyShortcutPostActivity7 when the shortcut's ID is prefixed with px, py, or pz.
INC-140701 · Issue 602862
The Report Resource Limit is applied on Job Scheduler
Resolved in Pega Version 8.3.5
The Job Scheduler was ignoring the application-wide limit for maximum number of rows to retrieve that was set on the Report > Settings landing page. If the limit was set on the Data Access tab of the report, it was honored. If it was set on the Application settings rule Pega-RulesEngine.pyMaxRecords it was not honored. This behavior was due to pzUpdateSystemSettings being called by pxRetrieveReportData. In pzUpdateSystemSettings, .pyContent.pyMaxRecords was updated to match the value in px.Requestor.pyReportSettings.pyMaxRecords. In some cases, that was not available and the max amount of records was not limited in that case. This has been resolved by updating pzUpdateSystemSettings to pull pyMaxRecords using @getRuleSystemSetting().
INC-121460 · Issue 569118
IH Summaries correctly loads aggregated count
Resolved in Pega Version 8.4.2
After the IH Aggregated DataFlow has processed more than 34 million records from an Oracle database, the IH Fact table contained only ~120,000 records. Running a browse on the pxInteractionHistory DS resulted in an infinite loop. Investigation showed that this was caused by the handling of Oracle timestamps: using Pega DateTime in query parameters generated Oracle DATE instead of TIMESTAMP, causing all query parameters to be rounded to the second and interfering with the IH pre-aggregation. This has been resolved by updating the handling.
INC-122180 · Issue 563270
Null check added for Entity Extraction result
Resolved in Pega Version 8.4.2
Training data for an Entity Extraction model was not getting distributed correctly, as per the given % data. This was due to the result of the Entity Extraction result being null, and has been resolved by adding a check that will consider detected types as primary candidate for grouping if the result column is null.