SR-D71621 · Issue 533295
Real time processing picks up correct datetime for Capture Response records
Resolved in Pega Version 8.2.6
A Realtime Data flow for the Capture Response flow was configured with a strategy shape set to load previous decisions within the past 7 days. Once this Realtime DF was started, attempting to Capture Response for decisions made after that startup timepoint did not work. This was traced to the InteractionID being written with global properties for the datetimes, and has been resolved by making those datetime properties local so the start and end time are not cached and the time range is calculated based on "now”.
SR-D74117 · Issue 539461
DDS service will not run Hazelcast check if external Cassandra is configured
Resolved in Pega Version 8.2.6
Services were not responding, and thread dumps seen in the logs indicated that a large number of threads were waiting for one to come back from getting the cluster state for a DSM process. Investigation showed that the threads were waiting for a Hazelcast response about the cluster state. However, since a Hazelcast call is not needed when Pega is configured with external Cassandra, the DDS Service code has been changed to not to check for candidate nodes if configured with external Cassandra cluster.
SR-D74247 · Issue 542916
Resolved errors when using Build Model from the Preview Console
Resolved in Pega Version 8.2.6
Using the Web Chatbot interface and trying to perform Build Model action from Preview Console failed with multiple errors, either "This action is not allowed as it is outside the current transaction" or "class <blank> doesn't exist". This was traced to issues with the transaction during model update, and has been resolved by conditionally disabling the show page step of pzGetModelProcessStatus. This step creates a difference in the context of the current transaction and is disabled when called from Update API.
SR-D78940 · Issue 542926
Dataflow monitoring enhanced
Resolved in Pega Version 8.2.6
Enhanced monitoring and healthchecks have been added for dataflow and alerts.
SR-D79909 · Issue 542244
DDS added for automated dataflow run cleanup
Resolved in Pega Version 8.2.6
During a recent upgrade it was seen that there were in excess of 20k dataflow runs, some 2 years old, which slowed down the migration significantly. In order to resolve this, an automated process has been added. This clean-up procedure deletes all the single case, batch, and real time runs older than 30 days which are in the final state - Completed, Completed with Failures, or Failed, and batch and real time runs which are in the Stopped state. The DDS Pega-DecisionEngine.dataflow/run/maxDaysToKeepRuns.should be used configure the retention period. Note that the retention period is calculated since the last processed message and not the creation time of the run.
SR-D82917 · Issue 545518
Revision Management updated for Marketing
Resolved in Pega Version 8.2.6
When Offers created outside of the CR context were deleted from Revision Managment LP using the Delete Rules option, the Offer was deleted but the Decision Data was not updated. This also happened when the offer was not included while submitting the revision. This has been resolved by providing the needed extension for deleting the offer rules in marketing.
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+.
INC-193632 · Issue 679172
Cassandra driver metrics exposed for performance troubleshooting
Resolved in Pega Version 8.7.1
By default Cassandra driver metrics are now enabled. Metrics can be disabled by setting the dnode/disable_driver_metrics prconfig parameter.