SR-D15262 · Issue 486888
GetNextWork properly switches applications for 'most urgent'
Resolved in Pega Version 8.3
Post upgrade, the "Get most urgent" button was unable to open a service request from another application to which the operator had access. In this case, the Operator had access to the Canada and USA applications by default, but when a service request from the Canada application context was available in the list, the Get most urgent functionality failed to switch the application context from USA to Canada in order to open the work item. Investigation showed that the GetNextWork activity was being overridden in the Pega-DecisionManager ruleset in rule resolution and that the the Pega-ProcessEngine and Pega-DecisionManager had different versions of the activity. This has been resolved by upgrading GetNextWork in the Pega-DecisionManager ruleset.
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-D42402 · Issue 508895
Added differentiated handling for special symbols based on location in the label string
Resolved in Pega Version 8.2.4
While importing an Excel file into a decision table that used custom functions like@string:notequal or equal, label names like 'AlphaPrefix !=AAA' resulted in the error "invalid expression or reference: line 1:28 extraneous input '"True"' expecting {<EOF>, '-', '+', '=', '*', '/'," " . Investigation found that the problem was with the label of the column not handling the the special characters like (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) present in the middle of the label string: the label and default operator were being updated irrespective of the location of the symbols within the string. To resolve this, DecisionTableWorkBookConverter.java has been modified to set the operator only if the special strings (‘!=’, ‘<’ , ‘<=’, ‘>’, ‘>=’ ) are present at the end of the label.
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.
SR-D27161 · Issue 503154
Step staus fail logic updated to handle agent activity exception
Resolved in Pega Version 8.2.4
Attempting to execute an advanced agent containing logic that set a step status to fail resulted in the error "Agent activity disabled due to execution errors; ErrorMsg: unable to execute agent: Cannot obtain a lock on instance as Requestor already has the lock ". This was traced to a backwards compatibility issue with previous work done to handle cases where agent activity requires authentication and agent has "bypass auth" flag set to false. Agent activity is not allowed to execute by the engine, and to show this scenario as exception case instead of showing it as running in admin studio, changes were made to rely on step status as the engine internally sets step status to false in this case. However, this inadvertently affected use cases where agent activity sets the status as fail in its logic. To resolve this, the system has been updated to handle the exception case and not consider StepStatus.
SR-D28719 · Issue 505967
Null archive check added to set import process status
Resolved in Pega Version 8.2.4
After running a 'prpcServiceUtils.sh import' which failed due to a low-level null pointer error, the job "IMPORTREQUEST-2" then incorrectly showed the status as 'IN PROGRESS' instead of 'FAILED'. In this case, the null pointer exception occurred because two imports were unintentionally happening at the same time: the process copied up the same set of archives to the service export directory, but the first import processed an archive and deleted it so that the second process failed to find it. When it exited with the null pointer exception, the status was not set to 'failed'. To resolve this, a null archive check has been added which will set the status to 'failed' if the archive is unsupported, corrupt, or not there at all.