SR-C37810 · Issue 381739
Agent management made more resilient against DB connection errors
Resolved in Pega Version 8.1
Intermittently after a database interruption occurred, agents would end up in a state where they did not run. When viewed via SMA they appeared to be running, but the next runtime was blank and the agent did not execute. Attempts to stop/restart an affected agent yielded an error, but restarting the system put the agents back into a operable state. This was a corner case caused by a DB connectivity issue where agents were first being stopped and then attempts to instantiate AgentNotification() also failed due to the DB connectivity issue. To resolve this, AgentNotification will be instantiated during AgentQueue creation itself so it will remain available. All exceptions /errors in AgentNotification will be logged.
SR-C39747 · Issue 383893
Added call to pyconvertedvalue to preserve number format in BIX extract filtering
Resolved in Pega Version 8.1
When creating a BIX extract rule with a filter of integer property on LHS and a constant integer value of RHS which is of 8-9 digits such as "filter : salary = 100000000" , saving the extract rule converted this RHS value to 100,000,000 and the filter showed as : "salary = 100,000,000" .In this scenario, running the extract rule generated an error in the log. This was traced to the system converting the filter value ( <pyfiltervalue> whose value is "100,000,000" ) to a number and causing a numberformat exception. This was a coding error that missed a call to supply <pyconvertedvalue>, and has been fixed.
SR-C45807 · Issue 384867
pyLabel will be truncated at 64 characters in the pyAttachApprovalEmail activity
Resolved in Pega Version 8.1
The pyAttachApprovalEmail activity was throwing the below error when trying to process an email response : "Trying to save an invalid page: page is not valid .pyLabel: "Incoming Email Message from [email protected]" is too long, maximum length allowed is 64"This was due to the maximum length restriction on the field pyLabel: in step 2 of activity, the pyLabel was set to ""Incoming Email Message from " + Param.EmailFrom", and the pyLabel restriction of 64 characters generated the error while saving the rule. To handle this case, the pyLabel value will be truncated at 64 characters before saving the Data-Corr-Email instance.
SR-C47633 · Issue 386353
Agent management made more resilient against DB connection errors
Resolved in Pega Version 8.1
Intermittently after a database interruption occurred, agents would end up in a state where they did not run. When viewed via SMA they appeared to be running, but the next runtime was blank and the agent did not execute. Attempts to stop/restart an affected agent yielded an error, but restarting the system put the agents back into a operable state. This was a corner case caused by a DB connectivity issue where agents were first being stopped and then attempts to instantiate AgentNotification() also failed due to the DB connectivity issue. To resolve this, AgentNotification will be instantiated during AgentQueue creation itself so it will remain available. All exceptions /errors in AgentNotification will be logged.
INC-170721 · Issue 658960
Stricter criteria set for reusing an SSAExecutionContext
Resolved in Pega Version 8.7
After a Strategy was configured with an existing Proposition Filter and the Explain Results box was unchecked, executing the strategy resulted in the error "Stack is empty, cannot pop any more frames". Investigation showed that the SSAExecutionContext object was reused across the two criteria evaluation in Proposition Filter rule: this works well as long as the input is the same across the two evaluations. However, the SSAExecutionContext object also stashed a reference to a PublicAPI object which became stale in the second evaluation and caused the empty stack issue for the given scenario. This has been resolved by providing stricter criteria in deciding when an SSAExecutionContext can be reused or not in the case of Proposition Filter rule.
INC-187103 · Issue 671737
Guided Tour working from Actions menu
Resolved in Pega Version 8.7
After updating from Pega 8.4 to Pega 8.5, "Manage a Guided Tour" was no longer working under a local action when called from the Actions menu on a work object. An unspecified error message appeared in the tracer. Investigation showed there was a null pointer error caused by the menu being invoked on an invalid page, and this was traced to updated authentication requirements: registration at the portal is not reliable as it is thread-scoped and run only once. The thread name is not guaranteed to stay the same so subsequent invocations of the tour activities failed. This has been resolved by modifying the call registration function to handle the security issues related to the generation of the menu path.
INC-199303 · Issue 690629
Guided Tour working from Actions menu
Resolved in Pega Version 8.7
After updating from Pega 8.4 to Pega 8.5, "Manage a Guided Tour" was no longer working under a local action when called from the Actions menu on a work object. An unspecified error message appeared in the tracer. Investigation showed there was a null pointer error caused by the menu being invoked on an invalid page, and this was traced to updated authentication requirements: registration at the portal is not reliable as it is thread-scoped and run only once. The thread name is not guaranteed to stay the same so subsequent invocations of the tour activities failed. This has been resolved by modifying the call registration function to handle the security issues related to the generation of the menu path.
SR-C23461 · Issue 365026
Exported Excel now displays text between angle brackets
Resolved in Pega Version 8.1
Using the Export to Excel feature on a Report Definition was stripping XML and HTML-like values from the data such as text between matching angle brackets. This was traced to recently modifications in Export to Excel: because the export generates an XLSX document and not an HTML document, HTML-like code is stripped from formatted values. However, that was being performed after unescaping special HTML characters and codes in the raw or localized value, and this caused HTML-like code in the data to be removed as well. To correct this, the system will strip HTML prior to unescaping special characters. In addition, columns which did not have valid controls assigned to them or their associated properties were borrowing logic from columns formatted by non-auto controls. This has been addressed by refactoring ReportUIFieldFactory to generate basic ReportUIField instances for unformatted columns, excluding numeric and date columns.
INC-182776 · Issue 666941
CheckFlowDependencies updated for auto-instantiated child cases
Resolved in Pega Version 8.7
A parent case with more than one child case was producing an unexpected behavior during the child case creation process. The first child case was instantiated at the correct point of the case stage based on its dependency condition, but the following cases were instantiated at the same point where the first child case was created irrespective of the dependency conditions defined in the other child cases. Investigation showed that the pxCheckFlowDependencies activity called from the Resolve activity was removing the named pages "pyTopCaseMap" "pyTopCaseWork" which are required for starting and validating configured auto-instantiate child cases in the pzCanStart function. To resolve this, an update has been made to CheckFlowDependencies which will use the activity "pzResolveCaseHierarchyMap" for removing the "pyTopCaseMap" and "pyTopCaseWork" pages based on DependencyType.
INC-190070 · Issue 676643
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.