INC-202937 · Issue 695941
RealTimeProcessingDelay made configurable
Resolved in Pega Version 8.7.1
When using interaction history summaries in Engagement Policy strategies, the check whether a particular action was sent previously was not returning any results for the customers that did have an action "Sent". These records were present in the IH Fact table but the IH Summary tables were missing these records. This has been resolved by making the realTimeProcessingDelay configurable for reading from IH in a real-time flow configurable (done as part of IH pre-aggregation). This may be useful if there can be a difference in time between machines inserting into IH which causes pre-aggregation to miss processing records. The relevant DSS is "interactionHistory/realTimeProcessingDelay", and the default is 5 seconds. This must be set before starting pre-aggregation. This is the difference between the end position and the log time. RuleSet: Pega-DecisionEngine DSS Name: interactionHistory/realTimeProcessingDelay Value: <new delay in seconds>
INC-205378 · Issue 698513
Added handling for double quotes on Substrategy shapes
Resolved in Pega Version 8.7.1
After update, there were compilation issues on calling substrategies from strategies using datapage.pxResults as another page. This was traced to the handling for a parameterized data page with double quotes on Substrategy shapes, and has been resolved.
INC-206684 · Issue 699365
Empty string handling added to SSA CompareDates
Resolved in Pega Version 8.7.1
The CompareDates implementation in SSA has been updated to fallback to the current datetime/date if it encounters empty string arguments.
INC-208207 · Issue 702800
#resolvedissues note:
GET API will consider case locking mechanism
Resolved in Pega Version 8.7.1
After update, performing a GET call on an assignment was unexpectedly locking the case. This was traced to a difference in handling: Pega 8.3 performed an Obj-Open-By-Handle of the workobject without acquiring a lock, while Pega 8.6 calls Assign-.acquireWorkObject which acquires a lock on the work object thereby affecting the other requestors from accessing the case. This has been resolved by enabling ConsiderLockingMode to independently determine the locking mechanism set for the case type.