SR-133183 · Issue 205535
Fixed flow line distortion in Process Modeler
Resolved in Pega Version 7.1.9
When clicking through to a subprocess from a parent flow (by clicking the + sign in the blue subprocess shape), flow lines in the subprocess were shown in a distorted fashion. When opening the same flow in a separate tab (by right clicking the blue subprocess shape and selecting Open Flow) the flow lines were correctly painted. This was an issue caused by the different renderings of the flow depending on whether there was a click through to it (with the + on the parent flow?s subprocess shape), or the subflow was opened in a separate tab (with open Flow). After the Process Modeler saved and checked-in the flow, the connector lines were re-drawn in ways that were non-intuitive and hard to interpret due to the edge routing in PM being calculated off incorrect input data that was taking into account shapes that were not represented on the screen. To fix this, the system now ensures the edges are routed without taking into account any shapes not represented on the canvas.
SR-133184 · Issue 203710
Fixed flow line distortion in Process Modeler
Resolved in Pega Version 7.1.9
When clicking through to a subprocess from a parent flow (by clicking the + sign in the blue subprocess shape), flow lines in the subprocess were shown in a distorted fashion. When opening the same flow in a separate tab (by right clicking the blue subprocess shape and selecting Open Flow) the flow lines were correctly painted. This was an issue caused by the different renderings of the flow depending on whether there was a click through to it (with the + on the parent flow?s subprocess shape), or the subflow was opened in a separate tab (with open Flow). After the Process Modeler saved and checked-in the flow, the connector lines were re-drawn in ways that were non-intuitive and hard to interpret due to the edge routing in PM being calculated off incorrect input data that was taking into account shapes that were not represented on the screen. To fix this, the system now ensures the edges are routed without taking into account any shapes not represented on the canvas.
SR-A1705 · Issue 205449
Fixed scrumboard intermittent failure
Resolved in Pega Version 7.1.9
After upgrading, it was seen that the scrumboard would intermittently fail to load, partially displaying and then hanging if the columns did not fit within the window boundaries due to the number of elements. This was traced to an error in the functionality that resizes parts of the scrumboard, and has been fixed.
SR-A4995 · Issue 213355
Fixed flow line distortion in Process Modeler
Resolved in Pega Version 7.1.9
When clicking through to a subprocess from a parent flow (by clicking the + sign in the blue subprocess shape), flow lines in the subprocess were shown in a distorted fashion. When opening the same flow in a separate tab (by right clicking the blue subprocess shape and selecting Open Flow) the flow lines were correctly painted. This was an issue caused by the different renderings of the flow depending on whether there was a click through to it (with the + on the parent flow?s subprocess shape), or the subflow was opened in a separate tab (with open Flow). After the Process Modeler saved and checked-in the flow, the connector lines were re-drawn in ways that were non-intuitive and hard to interpret due to the edge routing in PM being calculated off incorrect input data that was taking into account shapes that were not represented on the screen. To fix this, the system now ensures the edges are routed without taking into account any shapes not represented on the canvas.
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.
INC-193847 · Issue 695974
DSS added to allow masking of subjectID in alerts
Resolved in Pega Version 8.7.1
In order to allow customizing whether or not a subjectID is included in alerts, a DSS has been added to conditionally mask the subjectID from being logged. To use this, set the "alerts/maskIHsubjectID" DSS in the Pega-DecisionEngine ruleset to true to hide the pySubjectID.
INC-194810 · Issue 691884
Removed services check and added warnings for simulations
Resolved in Pega Version 8.7.1
Attempting to run an audience simulation resulted in the error "Running simulations is not possible, because the required services are not available. Contact your system administrator to enable the data flow and real-time data grid services". Investigation showed the @DsmServices.pxHasFunctionalNodes("DataFlow","Batch") function call contained in the 'when' rule pyUnavailableDecisionServices was returning false even if all the nodes were in the cluster and all the DSM Services were in NORMAL status. To resolve this, the services check has been disabled and the simulation run will show a warning or fail if a data flow run is queued for more than 30 secs or if there is an issue with querying the underlying metrics storage.