INC-158686 · Issue 628553
Date properties on DSMClipboardPages formatted by determined type
Resolved in Pega Version 8.6
When data flow data was sourced from a File type dataset, the destination data showed 2020101+ for a valid date like 20201016. This has been resolved by modifying the way Date properties are read for DSMClipboardPages: properties which are instances of Date will be formatted considering the type, which will be deduced with usage of "getType" method. Invocation of this method can decrease performance of DSMClipboardPages, so it will be executed only when property will be of date type.
INC-158813 · Issue 629485
Updated report handling for simulations using database output
Resolved in Pega Version 8.6
When running a simulation with a database table as the output destination, the pxObjClass property was not populating with a value in the results. This caused sub-reports to not be populated with data. Investigation showed that issue happened when the simulation output destination database table was inferred as an external table due to not having an exposed column for pzinskey. To resolve this, the pxObjClass and pxCreateDateTime properties, which were added to simulation output destination tables for compatibility with Report browser, will not be added to those tables when they are created. Instead, to address compatibility issues of simulation output destination classes with Report browse in the Customer Decision Hub, the pyDefaultSummaryReport has been brought up into the Data-Decision-StrategyExecution-ResultOutput class from the @baseclass.
INC-159332 · Issue 629618
Logic updated for finding 'Last' in Interaction History
Resolved in Pega Version 8.6
The 'LastReponseDate' and 'LastInteractionId' in the Interaction History summary data set were null. Investigation showed that reusing the ESM component in the aggregation dataset caused any assumptions made during the optimization of ESM to not be true anymore. To resolve this, the logic of the Last aggregation has been modified to not rely on a Last event which might not be stored in-state (such as optimization), but rather to use the list of events which is always stored.
INC-160277 · Issue 628159
Implementation updated to ensure consistent compareDatesByDays results
Resolved in Pega Version 8.6
When using compareDatesByDays in a filter shape within a strategy, the results of the expression were different between the expression test and the strategy test run. This was traced to a difference in handling that became visible after upgrade; giving a negative number for the numberOfDays parameter worked differently in v7.4 than in v8.4. The SSA implementation of compareDatesByDays always worked with the absolute difference in days between dates, whereas the Java function in Pega used in expressions did not, and would compare negative differences as well. To restore the expected behavior, the SSA implementation has been adjusted to not work with absolute differences, and tests have been added to ensure equal results for the Java function in Pega and the SSA implementation.
INC-160887 · Issue 629271
Resolved strategy optimization exception
Resolved in Pega Version 8.6
After upgrade from v8.2 to v8.5, Customer Decision Hub strategy failures were seen in the data join used with a datapage/page list to fetch some results. Errors appeared in the logs and UI. The exception indicated that the Strategy Parser for the new execution engine (SSA) was not able to parse and inline the used expression. Normally this exception would be caught in subsequent processing and the component where the exception is used would fall back to legacy so as to not affect the runtime behavior, but this scenario triggered a corner case inside the parsing logic for Data Join and Exclusion shape which caused the exception and stopped the process. To work around this issue, the Data Join configuration can be split into two shapes: create a new Data Import shape to only import the Page list, e.g. 'Page.pxResults', then on the original Data Join component, instead of joining the 'Page.pxResults', join with the new Data Import shape. This issue has been resolved by catching the exception when compiling the Data Join component and properly falling back to the Data Join shape.
INC-161604 · Issue 631764
Corrected unreleased database connections
Resolved in Pega Version 8.6
When using a custom activity that calls Dataset-execute on a database table dataset, the DSS Pega-Engine.prconfig/classmap/usemergestatement/default was set to false and the prepared statement for database table dataset was failing. Upon the failure, an exception was generated that prevented the database connection from being released. This has been corrected.
INC-161604 · Issue 631762
Node stability improved when adding relevant records
Resolved in Pega Version 8.6
A node was going down after maxing out the database connection pool whenever the inbound service call was invoked. This was traced to several relevant record-related database queries being invoked within a short time for marking 'when' rules referenced in the proposition filter rule as relevant records. This has been resolved by adding 'when' rules as Relevant Records based on a DSS and not adding auto-generated 'when' rules at all.
INC-163723 · Issue 633441
Queue Processors made more robust
Resolved in Pega Version 8.6
After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.
INC-164581 · Issue 634154
Import UI option updated to handle data import for upgrades
Resolved in Pega Version 8.6
After upgrade from Pega 8.1 to 8.5, importing data into the datasets using the Actions->Import UI option was not working. This was due to the previous save operation used in import being deprecated, and has been resolved by instituting a new save operation in import to handle this scenario.
INC-166354 · Issue 637300
Queue Processors made more robust
Resolved in Pega Version 8.6
After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.