INC-170721 · Issue 658962
Stricter criteria set for reusing an SSAExecutionContext
Resolved in Pega Version 8.6.1
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.
SR-B8133 · Issue 277199
Support added for cloning SLA agents
Resolved in Pega Version 7.3
The SLA worker agent was not working as expected based on a prior recommendation to clone agents. The cloned agents are not handling any requests. The original agent is still working, but all 3 clones do not perform any work. 6 nodes, for agents per node, and on each node only the original node is working. Cloned agents were not processing work in production if they were duplicated from SLA agents. In order to support this use, a new feature has been added to agent to allow dequeueing pages queued for another agent. This new configuration setting clones Pega-ProCom to multiple custom rulesets or creates a new agent rule in a custom ruleset with multiple rows for the ServiceLevelEvents agent in that rule. Example:
SR-B35117 · Issue 292760
Split-for shape "open flow" works as expected
Resolved in Pega Version 7.3
When working with a flow that contains a Split-for each shape which loops pyWorkParty and executes a flow on Data-Party class, an error was generated if there was a right-click on the sub-flow shape and "Open flow" was chosen. The sub-flow opened properly if there was a right-click on the sub-flow shape, "View Properties" was chosen, then a click on the "Open" icon right of the flow name. This was traced to the Top Class being passed for opening the flow rule in the Navigation rule "pyMenu" of "Data-MO-Activity-SubProcess-SplitForEach" class. To fix this, the class has been changed from Top to ".pyPageClass" in the Navigation rule "pyMenu" of "Data-MO-Activity-SubProcess-SplitForEach" to open the flow rule
SR-D3371 · Issue 439505
Association Resolver updated to handle filters created on secured properties
Resolved in Pega Version 8.3
After creating a Report Definition in a class (Example Class A) that had an Association in that report with Class B, no results were generated from the report when an Access Control Policy and Access Control Policy Condition were created for Class A and Class B where the Class B had an ACPC with a Value field that referred to a Data Page or clipboard page property. Investigation showed the system was not able to resolve the actual value of the datapage property in the generated SQL query due to Association Resolver resetting the filter value (the Page reference in this case) of a filter that is created on a secured property. This has been corrected by updating Association Resolver to not reset the right operand for a filter that is created on a secured property.
SR-D13388 · Issue 485167
Handling added for minor case creation errors
Resolved in Pega Version 8.3
When creating a case, if any step status failed due to a non-critical reason which did not impact case creation (for example, a mandatory parameter was missing from the data page), that failure state was propagated to SaveNew and ultimately to the case creation API. As a result of this failure report, no case ID information would be reported back to the requestor even though the case was created, and the API responded with status 500 - internal service error. This has been resolved by removing the StepStatusFail check from pzCreateCaseInternal so that non-breaking errors will not result in a 500 error, and a check has been added for page messages in svcAddWorkObject and svcPerformFlowAction so that validation messages are returned.
INC-172675 · Issue 649452
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.6.1
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.