SR-D35266 · Issue 509481
Check added to postOpenAssignment to support Ajax Container use
Resolved in Pega Version 8.2.4
After configuring an 'OpenAssignment' action on a begin button and giving the target as 'Dynamic Container', it worked as expected to open the assignment in a new tab on the Platform, but did not work from the Customer Service interaction portal. This was traced to the Customer Service portal using MicroDC to display the cases in the work area, which was not within the scope of the Ajax Container. Additional checks have now been added to the postOpenAssignment function to support this use.
INC-168253 · Issue 652547
Documentation updated for using Connect MQ with clustered queues
Resolved in Pega Version 8.7
After update to Pega Platform v8.6, an issue was seen with Connect MQ rules that used an alias queue. The support documentation has been revised to outline the necessary steps for updating an application to perform as expected. In the Pega-IntegrationEngine ruleset, create the following dynamic system settings and their default values: "mq/pmo" = 0 "mq/gmo" = 0 "mq/oo_request" = 1040 "mq/oo_response" = 16 For more information, dynamic system setting support articles are available.
INC-182959 · Issue 668737
SQL queries modified to use qualified table references
Resolved in Pega Version 8.7
Portal launch in the development environment was taking an excessive amount of time, as were some standard reports. The PurgeAssemplyDatabaseCache agent activity also generated an error regarding "(internal.cache.RAPurge) ERROR - Purge, unexpected error in removeOldAppCentricCacheData". These issues were traced to SQL queries that contained pr_sys_app_hierarchy_flat without a schema qualifier, and have been resolved by changing to class qualified table references.
INC-185760 · Issue 668742
SQL queries modified to use qualified table references
Resolved in Pega Version 8.7
Portal launch in the development environment was taking an excessive amount of time, as were some standard reports. The PurgeAssemplyDatabaseCache agent activity also generated an error regarding "(internal.cache.RAPurge) ERROR - Purge, unexpected error in removeOldAppCentricCacheData". These issues were traced to SQL queries that contained pr_sys_app_hierarchy_flat without a schema qualifier, and have been resolved by changing to class qualified table references.
INC-174933 · Issue 651829
Special characters escaped for use in "is in List" lookups
Resolved in Pega Version 8.7
After creating a specific criterion on any proposition using a string property, the "Is In List" operator, and a customer list with one value containing a "$", clicking save or check in resulted in the exception error "Problem invoking function: pega_decisionengine_propositionfilterfua.pzPropositionFilterMethodBody--(PublicAPI,ClipboardPage) java.lang.IllegalArgumentException: Illegal group reference at java.util.regex.Matcher.appendReplacement(Matcher.java:857) ". This has been resolved by escaping regular expression control characters in string replacement, which will allow the use of characters such as the $ sign for "is in List" lookups.
SR-D33934 · Issue 503333
Parent case lock properly released when child case is resolved
Resolved in Pega Version 8.2.4
After creating Parent-Child casetypes with default locking where the child case had the “Allow access to parent” check box checked, the temporary lock acquired on the parent during resolution of the child case was not released afterwards. If “Allow access to parent” was not checked, then the locks were released on both the parent and the child. This was traced to a combination of parameters used by the openIfStale() API where aUnlockOnCommit could be set to false despite the provided locking strategy expecting it to be true, as well as honoring UnlockOnCommit when maintainLockingStrategy is false. To resolve this, the system has been updated to always check whether the lock is available in the map already and if it is, then set unlockonCommit to true. Otherwise, under all cases, honor the passed-in unlockOnCommit value.
SR-D37945 · Issue 506799
Server node cache refresh will use remote execution timeout
Resolved in Pega Version 8.2.4
A campaign was failing due to VBD remote ping timeout with a stacktrace that indicated a StageException. Investigation showed that when the cluster is heavily loaded, calls to the remote execution API could time out. If this occurred when the VBD client was refreshing its cache of VBD server nodes, then the insert failed and the error was propagated up the calling data flow. To resolve this, the system will use the remote execution timeout when refreshing node cache, extend the timeout to 60 seconds, and ensure timeouts are retried during inserts.
INC-190130 · Issue 678541
Help information updated for using Elastic Search with Report Definition
Resolved in Pega Version 8.7
The support article "Configuring a report definition to run against an Elasticsearch index" has been updated to clarify that the search can pass multiple values with a space in pySearchString as it does OR operation on all the fields, and that filters in the report definition will be used when executing the report directly or when calling the report in the pxRetrieveSearchData activity. https://community.pega.com/knowledgebase/articles/system-administration/85/configuring-report-definition-run-against-elasticsearch-index
SR-D392 · Issue 438871
Behavior reset for using getLocalizedValue with an input string containing parentheses
Resolved in Pega Version 8.3
After upgrade, the getLocalizedValue function was not returning any value if the input string contained parentheses. This was a difference in behavior caused by a missed use case when correcting another issue, and has been resolved by resetting the system to the previous behavior of getLocalizedValue returning a localized string in cases where a Field value/Rule message is present, or otherwise returning the exact input string.
SR-C96153 · Issue 433373
Repository Delete API updated for better use with cloud storage
Resolved in Pega Version 8.3
Previously, the Repository Delete API immediately checked if a file existed after attempting to delete it. When deleting files in S3, the file may not be immediately removed: due to S3's eventual consistency policy, the file could still exist at the time Pega was attempting to verify the deletion but be "deleted" according to Amazon. This caused a false alert that the file deletion was unsuccessful, leading to alert emails being sent and the Manifest file not being created, and in some cases generating an exception. To resolve this issue, the logic in Repository Delete that checked if file existed after attempting to delete it has been removed.