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 629486
Updated report handling for simulations using database output
Resolved in Pega Version 8.5.3
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-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-150395 · Issue 625070
Tokenizer updated to handle commas
Resolved in Pega Version 8.5.3
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-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-143121 · Issue 610735
Timeout for loading predictors made configurable
Resolved in Pega Version 8.5.3
When using an extremely large number of predictors, the Report definition pzADMPredictorsFilter was suffering timeouts due to the time for loading predictors from the database exceeding the time threshold allowed. This has been resolved by marking the rule as editable to allow custom setting of the threshold according to need.
INC-151421 · Issue 614596
Adaptive Model Save-as works With Predictor Type
Resolved in Pega Version 8.5.3
A predictor change which was accounted for in a previous adaptive model rule version did not work on future save-as. This was traced to a missed use case that when the value 'pyPrevPredTransformation' is empty, validation on that is unnecessary. This has been resolved by adding an 'if' condition in the validation activity.
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.