INC-169125 · Issue 642400
Nodes resume correctly after DDS restart
Resolved in Pega Version 8.5.4
A corner case issue in VBD's code for handling a DDS session was preventing the nodes from recovering correctly after a system shutdown. As part of the process for an event which fires if all DDS nodes are taken down or as part of a switch from embedded to external Cassandra, VBD's cache is invalidated and then re-initialized once new VBD API calls are received or on the VBD service pulse. In this case, the invalidation of the cache did not complete due to logic in the VBD code that can lead to executing a Cassandra query that will not work in the case of all DDS nodes being down. This has been resolved by modifying the handling of a session change event to eliminate inadvertent Cassandra queries so the invalidation can complete correctly and continue the re-initialization process.
INC-169544 · Issue 649539
Enhancement for MaxEnt modeling data
Resolved in Pega Version 8.5.4
An enhancement has been added to create output for the model coefficients, the term frequency, and the inverse term frequency for use in maximum entropy modeling. For MRM processes, every Maximum Entropy (Maxent) based topic model will contain two additional stats resources. These resources can be used to validate and replicate running of topic model outside of Pega. The resources are: 1) Term Frequency file – A CSV file with all words used for training and their cumulative frequency across training set. File name format – TRAINING_DATA_TERM_FREQUENCY_< RandomNumber >.csv olumns – Word, Count 2) Coefficient file – A CSV file with all features (words, taxonomy matches and category matches) and model learnt weights for each topic across training set. File name format – MAXENT_COEFFICIENT_VALUE.csv Columns – Feature, < TopicName1 >, < TopicName2 > ,…, < TopicNameK >
INC-170149 · Issue 645724
pzTenantID removed from Revision management classes
Resolved in Pega Version 8.5.4
After upgrade, issues were seen with case types in the case explorer. This was caused by the Revision management work classes created in the 7.1.x version having pzTenantId property in the rule XML when it was not defined anywhere in the 8.x versions, and has been resolved by removing the pzTenantId property from the Revision management classes.
INC-171221 · Issue 645988
Queue Processors made more robust
Resolved in Pega Version 8.5.4
After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.
INC-174933 · Issue 651827
Special characters escaped for use in "is in List" lookups
Resolved in Pega Version 8.5.4
After creating a specific criterion on any proposition using a string property, the "Is In List" operator, and a customer list with one value containing a "$", clicking save or check in resulted in the exception error "Problem invoking function: pega_decisionengine_propositionfilterfua.pzPropositionFilterMethodBody--(PublicAPI,ClipboardPage) java.lang.IllegalArgumentException: Illegal group reference at java.util.regex.Matcher.appendReplacement(Matcher.java:857) ". This has been resolved by escaping regular expression control characters in string replacement, which will allow the use of characters such as the $ sign for "is in List" lookups.
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.