INC-181401 · Issue 665935
Added handling for MS SQL datestamp format
Resolved in Pega Version 8.6.2
When using an Microsoft SQL Server, the browse operation was failing with an SQL error for the pyIHSummary dataset. Investigation showed there were some datasets that generated SQL statements with a date timestamp format that SQL was not able to handle implicitly, affecting browsing but not functionality. This has been resolved.
INC-182137 · Issue 662487
Multistage Prediction Logic improved
Resolved in Pega Version 8.6.2
When Predictions with Response wait time configured were executed as part of make decision, each decision that came out of the strategy caused a pxDR call to fetch the relevant model execution results and process them to stage the default outcome results for models. This has been improved by modifying the system to process the existing records rather than reading data again from pxDR.
INC-183431 · Issue 665161
Strategy execution queries tuned
Resolved in Pega Version 8.6.2
During NBA strategy execution, interaction history summaries were queried multiple times for a single strategy execution. To improve this function, the isChanged query will now be executed once after system startup if there are no changes instead of being executed every time the Aggregates DataSet BBK is executed. If the same Aggregates query is made multiple times as part of a Strategy in a REST request (i.e. likely multiple ADM models in a MakeDecision call), only one Aggregates BBK call will be made.
INC-185045 · Issue 672418
Performance improvements for action check-in
Resolved in Pega Version 8.6.2
The process of 'Saving As' an action to a higher ruleset, Saving, and then running Check-in was taking an excessive amount of time. This was traced to redundant page copy activities and performance has been improved by updating the implementation.
INC-186889 · Issue 674015
Unused DSS compiledExpressions now defaults to false
Resolved in Pega Version 8.6.2
After updating from Pega 8.2 to Pega 8.5, executing a test campaign failed with an error in logs. This occurred when running Distribution tests with "Include funnel analysis reports" checked, and was traced to the DSS setting "decision/strategy/ssaVM/compiledExpressions". As this was previously used to toggle a feature which is no longer in use, the default setting for this DSS has now been changed to false to resolve this issue.
INC-188389 · Issue 672761
ComponentName fallback added for toggling page context
Resolved in Pega Version 8.6.2
Whenever the External Strategy configuration was changed from "Another Page" to "Current Page", pyComponentName property was not being created. This was a missed use case for toggling page context for external substrategies in the user interface of the strategy designer, and has been resolved by setting pyComponentName to its default if reset when switching context.
INC-188419 · Issue 671500
DSS added to configure usage of Topup
Resolved in Pega Version 8.6.2
During NBAD-generated strategy execution, each interaction history summary is queried twice to check data relevancy. This update adds configuration options to disable topup in aggregate datasets. Topup can be disabled with the following configuration items:- Set prconfig "ih/aggregates/last_customer_update_method" to NONE - Set DSS "cep/aggregates_dataset/partition_proc_cache_time" to -1
INC-203994 · Issue 698853
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.
INC-180246 · Issue 699700
Support for apostrophe added to keyword tokenization
Resolved in Pega Version 8.7.1
A keyword containing an apostrophe was not detected properly in Text extraction model. This has been resolved by updating the annotator used in the tokenization.
INC-193399 · Issue 688115
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.