SR-D23490 · Issue 496576
Interface changes made to avoid unexpected workitem deletions when removing stale locks
Resolved in Pega Version 8.1.6
Attempting to delete lock instances of work objects by directly opening the lock item found through navigating to (Dev Studio) App > Classes > System-Locks actually resulted in deleting the work item instead of just the lock. This was due to System-Locks being uniquely identified by the WorkItem that they belong to rather than having their own specific key. This meant that clicking on one of the instances caused the system to respond by presenting a "default RuleFormLayout section" which included a delete button keyed to the actual workitem, but this was not made explicitly clear in the interface. In order to prevent unexpected item deletions, the table has been replaced with a link to the proper System-Lock interface, specifically the "My Locks" window.
SR-C93264 · Issue 437311
Inference engine enabled to resolve JourneyManager data flow exception
Resolved in Pega Version 8.1.6
Customer environments were intermittently seeing an exception with the error "Could not get ultimate primary destination for data flow .DF_JourneyManager" when trying to compile an activity that ran a dataflow that ultimately called the DF_JourneyManager data flow. This error was traced to the Inference engine being in a disabled state so the system was not able to get the dataflow output class via declare expressions. The Inference engine has now been enabled to resolve this issue.
SR-D1458 · Issue 437895
Property name mapping moved to DSM side to ensure consistent results
Resolved in Pega Version 8.1.6
If a Data Set rule was used to retrieve the records of the Data Class, the property names appeared to be changing randomly in the OperationResult Clipboard Page when the name exceeded 30 characters. This was traced to NativeSQL trimming and hashing any aliases that were longer than 30 characters, and has been resolved by moving the mapping back of property names to the DSM side.
SR-D1575 · Issue 483121
Added check for null work page in Pulse task
Resolved in Pega Version 8.1.6
After upgrade, the message "Error in Pega Log file:Unkown Error: Error during while executing pulse task: SingleCaseMetricsManagerFlush java.lang.NullPointerException: null" appeared while executing Pulse task. This was traced to a null workObjectPage, and has been resolved by adding a check for a successfully created work page.
SR-D17907 · Issue 489174
Resubmit task now moves partitions to end state before restarting
Resolved in Pega Version 8.1.6
Resubmitting a failed task did not put the partitions into an end state, resulting in queue processor failure that did not automatically restart as expected. This has been fixed by modifying the resubmit task to move partitions to end state.
SR-D14201 · Issue 485965
Multitenant system pulse receiver will parse originating tenant name to facilitate data page removal
Resolved in Pega Version 8.1.6
When using a node level data page on a cloud multi-tenant system to get the data from a data table, attempting to flush the data page by explicitly calling pzFlushDataPage was not flushing the page in all nodes of a tenant. This was traced to the system pulse used to communicate between multitenant nodes: the receiver node was not removing the data even after receiving the system pulse because the cache contained the page with a different key. The key formed contained the tenant name, and the receiver was not parsing the tenant name from the pulse message received. To resolve this, the system has been updated to parse the tenant name from the pulse message and set it on requestor. This allows the correct key to be formed, allowing the receiver node to remove the data page as expected.
SR-D18200 · Issue 492099
Whitelist security added to getDataPage API
Resolved in Pega Version 8.1.6
In order to secure data pages that may be exposed through using Global Resource Settings with the pega.api.ui.actions.getDataPage API, logic has been added to expose only mentioned data pages from the clipboard through pyPublicDataPageWhiteList.
SR-D20817 · Issue 499921
Async cache checking updated for interaction reload use
Resolved in Pega Version 8.1.6
A thread level data page using connect REST to get data from an external system with the "Reload once per interaction" checkbox ticked was being loaded asynchronously from the activity when by default the data page it was supplying needed to be loaded synchronously. Due to this, changes to the data in the external database were not reflected in the data page. This was caused when an async cache was referred and the freshness check for the data page instance did not consider the 'reload once per interaction' flag because it would cause the data page to load twice. The cache checking has been updated to resolve this.
SR-D21776 · Issue 493779
Corrected freshness check for async cache
Resolved in Pega Version 8.1.6
A node level data page with time based refresh strategy was getting refreshed before the time out and many Pega0045 alerts were observed. Investigation showed the Load-DataPage activity step was causing the data page to be requeued and reloaded even if the earlier asynchronously loaded data page was fresh. This was due to a timing issue with the multiple asynchronous load of a data page where the freshness check for the already loaded instance was done before queuing the data page load, causing the check to fail. To resolve this, the freshness check will be performed on the instance which is present in the asynchronous cache if the instance in synchronous cache is stale.
SR-D1270 · Issue 488262
DB table mapping will check for existing properties before creating them
Resolved in Pega Version 8.1.6
Using the Database table class mapping tool to map an external database table to a class and create properties according to columns in the table was resulting in the property being created as 'not available' and not case sensitive if the property to be created while mapping was already present in the inheritance hierarchy. This led to an error caused by the property validation failing in the validateReportDesignTab activity. Previously the database table mapping tool did not check to see whether the properties to be created existed already in the parent class hierarchy. With this update, the system will check before allowing the mapping, and if the properties exist in the hierarchy already they will not be populated.