Resolved Issues

Parent case lock properly released when child case is resolved

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.

Server node cache refresh will use remote execution timeout

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.

Behavior reset for using getLocalizedValue with an input string containing parentheses

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.

Repository Delete API updated for better use with cloud storage

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.

Repository Delete API updated for better use with cloud storage

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.

Added when check for Strategy and Event Strategy to preserve pagelist property

When editing a test case that has been built from a strategy, clicking on the 'add properties' link in the side panel was not working. This was traced to the strategy rule being loaded each time while the data page is only loaded once per session, and has been resolved by adding a 'when' condition to the Strategy and Event Strategy rule that will check for the existence of an embedded page before the pagelist property which displays results is removed.

Work Object lock released correctly when modal dialogue is canceled

The Work Object lock was not being released when the modal dialogue cancel button was clicked. This was due to the primary page not being switched to the pyWorkPage during the cancel, and has been fixed.

JavaILCompiler updated to skip a type convert when generating code for a ternary operation

A compilation error was generated when attempting to save a Data Transform with a java expression giving the ternary as boolean. In this case, the pyWorkPage.Channel was set to  @java("tools.findPage(\"TempInputAccelPage\").getProperty(\"Channel\").getMessageCount()>0") ? "" : pyWorkPage.Channel.

The system previously used EL code generation, which had a gap which allowed such expression to work. Since the system now uses IL code generation, this expression failed. In order to ensure backwards compatibility, logic has been added to  JavaILCompiler to skip a type convert when generating code for a ternary operation where the source is ILProgramText (java expression).

Force order added to inner join when running a Rules Resolution filter

After upgrade, D_getResolvedWorkStatuses was not loading properly due to a Report Definition that used a Filter by Rule Resolution option timing out on the SQL Server. When the Filter by Rule Resolution option is selected in Report Definition, it will generate a rule resolution query with an inner join which can cause a time out on the SQL Server while it tries to find out the join order for tables with multiple joins. To resolve this, the SQL server will provide a Force order, merge inner join hint option by way of an added DSS reporting/useForceOrderHint. Additionally, reporting/useMergeHintForRRquery should be set on Pega-Reporting to set things up for using the Merge Inner join hint in the query.

Force order added to inner join when running a Rules Resolution filter

After upgrade, D_getResolvedWorkStatuses was not loading properly due to a Report Definition that used a Filter by Rule Resolution option timing out on the SQL Server. When the Filter by Rule Resolution option is selected in RD, it will generate a rule resolution query with an inner join which can cause a time out on the SQL Server while it tries to find out the join order for tables with multiple joins. To resolve this, the SQL server will provide a Force order, merge inner join hint option by way of an added DSS reporting/useForceOrderHint. Additionally, reporting/useMergeHintForRRquery should be set on Pega-Reporting to set things up for using the Merge Inner join hint in the query.