INC-177512 · Issue 657015
Hazelcast packages expanded for Java9+ with kubernetes
Resolved in Pega Version 8.7
Hazelcast warnings were seen in cluster logs when Hazelcast was run in embedded mode or c/s mode on a java modular environment i.e. java 9+ which noted that performance and functional impact issues may result if certain internal modules of java are not given reflection access. This update provides the necessary access to some additional java internal modules/packages per the Hazelcast recommendation.
INC-184155 · Issue 673072
Entity Detection prefers first detected entity
Resolved in Pega Version 8.7
Entity detection shown in the "Training data" tab of the email channel did not match with the results of running the corresponding text analyzer rule. This occurred when a single piece of text was detected as multiple entity values, which led to the last entity detected being picked for case mapping because of the unclear scenario of duplicate entities. To resolve this, pxmapresponseentities has been updated to prefer the first detected entity.
INC-184834 · Issue 669458
Channel copy text analyzer detection updated
Resolved in Pega Version 8.7
The error message "No unlocked Ruleset versions are available. Please add or unlock a ruleset to create a new channel." was displayed when trying to save a new interface. This was traced to the system copying the channel to incorrect classes/names due to detecting an incorrect type of text analyzer and copying the wrong rules. To resolve this, the method of detecting the text analyzer type on channel copy has been updated.
INC-145425 · Issue 600773
New email template added to include full message history
Resolved in Pega Version 8.5.2
Whenever a reply was sent from the email triage case, the outbound email sent only the actual reply along with the original email and latest reply only, skipping all remaining replies from email. For example, if there were 5 replies from case, replying 5th time generated an outbound email that contained only 5th reply (actual / current), original reply (which created the service case) and the latest reply (reply 4 in this case) and skipped reply 1 and reply 2. To resolve this, a new Outlook-style template has been added for use in replies that will include all of the previous exchanges.
INC-195354 · Issue 682183
Handling updated for UpgradeBeforeOpening
Resolved in Pega Version 8.7
After update, an email case paused for 1 minute with a wait shape and then resumed by a ServiceLevelEvents agent seemed to lose the context (class) of the case and went into the broken processes queue with the error "Unable to open an instance using the given inputs: pxObjClass = "Work-Channel-Triage"". This was traced to an incorrect class applied by the activity OpenAndLockWork which assumed that "Work-Channel-Triage" was the preferred class and passed in the case ID as a parameter. To resolve this, pzUpgradeBeforeOpening has been updated such that it will migrate a case only if it has "WORK-CHANNEL-TRIAGE" in the work object inskey.
INC-150367 · Issue 606028
Double quotes escaped in entity mapping
Resolved in Pega Version 8.5.2
A usecase where the BOTS created the triage cases from the emails and pushed it to the Workgroup had an intermittent problem where the screen would freeze and no actions could be performed. perform any action on the same. Investigation showed this occurred when the entity text contained double quotes which is caused JSON to break on the client side. This generated an exception during rendering, and other onload scripts failed on load and blocked the entire thread. To resolve this, the system will now avoid the JSON break by escaping double quotes in entity mapping.
INC-146595 · Issue 604789
Initialized entryName for light weight inventory instance
Resolved in Pega Version 8.5.2
When running deployment on a new pipeline created for the next minor version, once the deployment process got to the point of showing aged updates, the “view aged updates” came back as blank screen. Viewing the logs showed the aged update elements come back but were missing the pyName associated with them. Investigation showed that the system did not have support for setting the mEntryName for LightweightInventoryInstance objects. This has been resolved by adding a junit to ensure that getEntryName() doesn't return as null and should be equal to pzInsKey.
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.
INC-193153 · Issue 686293
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.
INC-201338 · Issue 690896
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.