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.
SR-D9198 · Issue 485218
Connections leak fixed for data-admin-db-table Oracle DB connections
Resolved in Pega Version 8.1.6
When exporting a product that contains a lot of Data-Admin-DB-Table instances to extract (>180), JBoss was crashing due to losing the connection to the DB as it reached the maximum number (100 connections) of DB sessions created during the export. Each time the export was launched, new connections were generated in the pool of ORACLE DB sessions that were never closed except by rebooting the environment. This was traced to a connection leak scenario within SQLGenerator.getCaseSensitiveColumnNamesForTable where a connection was being taken out inside a different try/finally block than where the connection was being closed, so the connection could potentially never be returned. This has been corrected.
SR-D10889 · Issue 482667
Intervals for DateTime control inside table grid corrected
Resolved in Pega Version 8.1.6
The "allow time to be displayed in the interval of minutes" feature did not work as expected for a DateTime control configured inside a table grid. If a value for minutes was chosen, say 30 minutes, it displayed all the minutes from 00 to 59 instead of displaying 00 and 30. The same control used inside a simply dynamic layout worked correctly, displaying 00 and 30. This has been resolved by adding logic to support having only time with drop downs.