INC-156818 · Issue 628465
Materialization uses time limit boundary for query
Resolved in Pega Version 8.4.5
After turning on Materialization for pyIHSummary and OfferOutcomesForPast45Days datasets, an SQL query was taking an excessive amount of time and causing multiple alerts in the logs. Investigation traced the issue to database partitioning, specifically that running a query where the pyOutcomeTime range spanned multiple partitions was causing the indexes for all partitions in the range to be opened. To resolve this, the query has been updated with a DSS to support a partition size of min(pxOutcomeTime) to limit the time range to querying day by day, or hour by hour, or any other chronology unit specified. If there are no records for the current limit, then it will look at the next partition. This should prevent the query from needing to open more than 1 or 2 partitions.
INC-158813 · Issue 629484
Updated report handling for simulations using database output
Resolved in Pega Version 8.4.5
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-200218 · Issue 692431
Added handling for calling truncate with external Cassandra
Resolved in Pega Version 8.7.1
A JMX exception was generated when using external Cassandra. This was traced to the combination of calling truncate and using external Cassandra for DDS, and has been resolved by adding a 'do not execute' consistency check during a truncate operation when using external Cassandra.
INC-150395 · Issue 625068
Tokenizer updated to handle commas
Resolved in Pega Version 8.4.5
The Text Analyzer was not working as expected in cases where the number was combined with a comma (,) with it but was working when a space was used between the number and the comma. This was traced to the tokenizer not correctly processing and splitting the input text when there was a special character before or after the token. This has been resolved by updating the tokenizer logic.
INC-175707 · Issue 655349
Multi-level strategy gives correct rules during Batch run
Resolved in Pega Version 8.4.5
When using a nested page structure with multi-level strategies that loop through each page and process the customer, a customer with two linked customers A and B had the results of A overridden by B during Batch Processing while single case canvas testing showed the correct results. This was caused by the DSM clipboard page method of carrying the parent page info not supporting the re-use of pages, and has been resolved by adding an enhancement that will sanitize the strategy stage processor to ensure the correct page reference is used.
INC-173859 · Issue 652640
Corrected compilation error for Decision Data component in Strategy
Resolved in Pega Version 8.4.5
After upgrade, a Decision data component defined in Strategy generated an assembly error when looking for class properties. This was traced to the use of "applies to" Instead of SR class, and has been resolved.
INC-195197 · Issue 692147
Warnings added to prevent empty StrategyResult page
Resolved in Pega Version 8.7.1
When a Proposition Filter rule refers to a When rule that has "StrategyResult" declared in Pages & Classes but no "Param.StrategyResult", a design time warning will appear to indicate that this might cause discrepancy in globally optimized strategy (GOS) execution. * The warning message for a When rule with StrategyResult in Pages & Classes but not in Parameters: When rule [WhenClass: WhenName] does not have proper mapping for [StrategyResult] page. This would result in an empty [StrategyResult] page being passed into the When rule during execution. Please go to [WhenClass: WhenName] and add [StrategyResult] in the Parameters list and configure the mapping properly on Proposition Filter rule. * The warning message when StrategyResult is not in Pages & Classes but in Parameters list: When rule [WhenClass: WhenName] declares [StrategyResult] in Parameters tab, but isn't used in the conditions. This would affect performance during execution. Please remove the parameter from When rule [WhenClass: WhenName], and remove the Parameter mapping from the corresponding Proposition Filter criteria.
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-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+.
INC-174550 · Issue 658394
Alternative pyLabel source for Auto-generated Proposition Filter added as fall back
Resolved in Pega Version 8.4.5
After using save-as to move an offer/action rule containing eligibility criteria into a new ruleset /branch, the criteria disappeared. Proposition Filter has an explicit dependency on relevant records, and in this scenario investigation revealed all of the relevant records had been previously deliberately deleted. Using save-as on auto-generated CDH rules like actions is also not a best practice. To better handle unexpected actions like these and avoid the hard dependency on Relevant Records, when creating the Proposition Filter via the programatic API the system will fall back to reading the label from the sourcePage if is not possible to get the label from Relevant Record.