SR-D43912 · Issue 509738
Fallover stategy added to chat routing to keep event processor running
Resolved in Pega Version 8.4
Chats were becoming stuck in the queue and end users were not able to connect with the customer service representative. An excessive number of queued items were observed in a Queue Processor named "EventProcessor". This was traced to the setting "Browse from the offset" having been removed because of a retention policy. This resulted in "Browse from the end of the stream" being used instead even though browse should start from the earliest known offset. To resolve this, Stream Producer will be cached based on topic, and Stream consumer will fall over to an earliest strategy in case the requested offset isn't found so the event queue will be handled in a timely manner.
SR-D44159 · Issue 512448
Refined Change Request creation logic
Resolved in Pega Version 8.4
Once a Change Request was terminated/closed with the X button available on the UI, the Change Request was created but could not be opened from the Report Manager landing page. Investigation showed that a change request created from the new revision button or create change request in the refine selection screen did not yet have pyLabel available in the CR because the assignment would not be submitted at this stage (Refine selection screen). Once the assignment was submitted, the pyLabel value would be committed to the database and be available in the change request. To resolve this, the CR creation rules have been modified and will set the pylabel value.
SR-D45608 · Issue 519903
Correct service instance name passed for data flow in DSMStatus
Resolved in Pega Version 8.4
When using the Connect-HTTP service "DSMStatus" to provide the node and status information as seen on the various tabs of the Designer Studio > Decisioning > Infrastructure > Services landing page, using DataFlow as the service parameter for the HTTP service method resulted in an empty response when the expectation was to get the information regarding the cluster details of Dataflow node type. This was traced to the service instance name not being parsed correctly when used for Data Flow services, and has been resolved by ensuring the correct service instance name is passed for this use.
SR-D45698 · Issue 511090
Edit available rules now available for rules created in revision management control
Resolved in Pega Version 8.4
New rules created in a revision management context could not be removed from the overlay using the edit available rules functionality. This was caused by the delete button against all new rules being disabled due to the 'when' rule pyDisableDeleteInIncludedRules always being true for new rules created in revision management context. When new rules are created in the revision management context, the pyNewRuleInLP property will always exist and its value will be false. If a revision involving the new rule has not yet been submitted, the new rule is not displayed in the list of available rules at all. When the rule is displayed after the revision is submitted, the pyNewRuleInLP property value will always be false. In order to support the editing of rules in this scenario, the 'when' rule Data-Rule-Summary.pyDisableDeleteInIncludedRules has been updated so that instead of the "property pyNewRuleInLP exists and has value" check, there is now a "property pyNewRuleInLP is true" check.
SR-D47618 · Issue 512603
Statistic rounding error in ADMSnapshot Agent with Oracle corrected
Resolved in Pega Version 8.4
While running the ADMSnapshot Agent, the exception "internal.mgmt.Executable) ERROR com.pega.decision.adm.client.ADMException: Failed to complete ADM Data Mart snapshot" was seen. This was traced to an issue with the rounding of performance statistics when using Oracle, and has been resolved.
SR-D47713 · Issue 511971
Corrected issue with strategy framework testing
Resolved in Pega Version 8.4
Issues were seen in creating a dataflow to test the strategy framework shipped with the Pega Marketing product. It was not possible to use a data transform to test this strategy because it is in the shipped PegaMKTEngine ruleset. Investigation showed the value of appliedToClass was retrieved from "pyRunOnDataFlowClassName" instead of from the running strategy, and this has been resolved.
SR-D50345 · Issue 513609
Performance improvement for Interaction History
Resolved in Pega Version 8.4
Interaction history was causing a performance issue due to pySubjectID being hard coded in the query while the clause values disabled query caching. To resolve this, a bind variable will be passed when using a single subject ID select call to the FACT table in the Inbound queries.
SR-D51017 · Issue 517182
Expanded date format handling
Resolved in Pega Version 8.4
The xx in the xx:yy time format was incorrectly detected as a year. To correct this, support has been added for the use case of the date followed by time.
SR-D52051 · Issue 515376
Corrected EditElement disappearing after DDR import
Resolved in Pega Version 8.4
After importing a DDR to a 'treatment', the section disappeared. Because the treatment decision data rules are created in the top level SR class, when the treatments are exported from these rules, the pyIssue and the pyGroup classes are empty in the exported CSV. When new treatments were added or existing treatment are modified in the CSV and imported, the pxObjClass for the treatments was set to Data-pxStrategyResult as the pyIssue and pyGroup were empty in the imported CSV. To correct this, pySelectedClass will be set to the propositions instead of pxPage.pxObjClass while importing.
SR-D52723 · Issue 516092
Data join conditions representation updated to avoid overwrite
Resolved in Pega Version 8.4
After upgrade, a Data join component on the Strategies was not working as expected, especially the ones using the DateTime function. If the data join conditions were swapped, i.e the DateTime function was not the last criteria, the strategy outputs were correct.Investigation showed that the implementation used a map to represent pairs of left and right expressions which caused conditions rows with the same leftExpr to end up overwriting one another. This has been corrected by fixing the representation of conditions of a Data Join to a list of tuples which eliminates the possibility of one condition overwriting a previous one.