INC-231505 · Issue 733974
Error handling improved for NBA run
Resolved in Pega Version 8.8
The data flow partition on a node was sporadically becoming stuck during a Next Best Action Campaign outbound run when it encountered an issue such as a NoClassDefFoundError, requiring the node to be restarted to clear the problem. This has been resolved by explicitly making sure the flow partition is failed when an input thread dies or there is an error in the dataflow.
INC-231704 · Issue 741219
Email template fragment updated to correct footer handling
Resolved in Pega Version 8.8
After creating a new Email correspondence rule and configuring the place holders as per the selected template, when the preview was rendered the "Footer" verbiage was being displayed irrespective of the footer region configurations. This has been resolved by updating the template fragment.
INC-231808 · Issue 735286
Heuristics moved from individual Annotator to Operations for consistent tokenization
Resolved in Pega Version 8.8
Because tokenisation heuristics were part of annotator and not part of operations, rule-based taxonomy loaded token operations directly, bypassing these heuristics and resulting in different tokenization outcomes for taxonomy keywords and analysis time text. Due to this discrepancy, emails were getting tokenized and not matching analysis time content. This has been resolved by moving heuristics from individual Annotator to Operations for tokenization to be consistent.
INC-231889 · Issue 736490
Email Parser updated with entity models and datatype casing
Resolved in Pega Version 8.8
When the email bot receives a message, all of the content plus the appended disclosure statement added by the mail server is considered. This was causing issues when words in the disclosure matched words added in the actual email body as keywords, causing the email bot to pickup multiple categories matching these words and not routing the service case appropriately. This has been resolved by adding AnalysisType.ENTITY in the analysisType list for pre-processing models and updating the logic to find out if entity extraction is selected or not (without using the analysisType list). In addition, an issue where pxEmailParser model was not running in the email channel due to an issue with preprocessing model datatype casing has been resolved by updating ExecutePredictionInPRPC to lowercase the datatype after reading from the text analyzer rule page, and then perform the comparison.
INC-235876 · Issue 741896
Corrected Schema inconsistency in pxDR after update
Resolved in Pega Version 8.8
After running make decision and capture response data flows using delayed learning and populating the pxDecisionResults data set, updating the system to Pega 8.7 and running capture response data flow with interactions from before the update resulted in the error "DataStoreConnection$InconsistentTableSchemaException: Inconsistency in table [data.pxDecisionResults_Pega_DecisionEngine_ab5de04587] schema between data store and schema repository". This was traced to a difference in DDS Data Sets pre- and post- introduction of DDS SDK and Data-Admin-DDS-Table. To ensure better backwards compatibility, an update has been made to ensure DdsDataSetFactory checks for Data-Admin-DDS-Table record existence in the dataabse, and if found uses tableName from that D-A-D-T. This resolves inconsistencies of the case of the table name.
INC-237193 · Issue 744028
Error handling improved for NBA run
Resolved in Pega Version 8.8
The data flow partition on a node was sporadically becoming stuck during a Next Best Action Campaign outbound run when it encountered an issue such as a NoClassDefFoundError, requiring the node to be restarted to clear the problem. This has been resolved by explicitly making sure the flow partition is failed when an input thread dies or there is an error in the dataflow.
SR-D90367 · Issue 556687
Cleanup enhanced for long pyEditElement names
Resolved in Pega Version 8.5
A pyEditElement error relating to decision data was seen multiple times in a stack trace. Research showed that while the utility worked as expected for decision data rules with names of less than 30 characters, the pyEditElement section was truncated the name for the decision data. This meant that decision data with the name SampleIssueandSampleGroupTwosalkdjkightntbmkblffvfvfv would be saved as SampleIssueandSampleGroupT for the pyEditElement section. Because of this, the utility failed the match and did not clean up the pyEditElement section. To resolve this, the cleanup utility has been updated to handle pyEditElement sections of decision data with longer names. Additional logging has also been added to improve debugging.
SR-D71621 · Issue 533296
Real time processing picks up correct datetime for Capture Response records
Resolved in Pega Version 8.5
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-D85558 · Issue 548286
Handling added for prolonged Heartbeat Update Queries
Resolved in Pega Version 8.5
After restart, the pyFTSIncrementalIndexer queue size had hundreds of thousands of entries even though it was empty prior to the restart. Investigation traced this to a job scheduler that checked all the database connections everyday at 1 EST by using a list that contained some connections which did not exist. Checking those invalid connections caused other update queries to queue and wait, resulting in the update heartbeat query taking longer than its default beat. This caused a Split Brain issue wherein other nodes considered the long-executing node to be dead and triggered a rebalance while the node itself continued to execute partitions thinking that it was healthy. This caused duplicate processing of records. To resolve this, a fail safe has been added: while updating heartbeat in Service Registry, nodes will enter safe mode when the update query is taking longer than the default beat.
SR-D66397 · Issue 530333
ADM out-of-sync corrected for multi-datacenter Cassandra cluster
Resolved in Pega Version 8.5
After setting up the multi-datacenter configuration for a Cassandra cluster that consisted of six nodes in datacenter 1 and three nodes in datacenter 2, failover testing revealed a mismatch in the number of ADM models stored in each datacenter. The mismatch was observed mostly in the number of records present in the "adm_scoringmodel" and "adm_response_commit_log_date_tiered" tables. When Cassandra nodes are down, the other nodes in the cluster will store hints (records to be written) for the down nodes. When these nodes come back online the hints are replayed to those nodes and the data is written. Hints are written for 3 hours, so if a node come back up within 3 hours data is recovered and repairs are not required. The gc_grace_seconds for the above tables that were getting out of sync across the two datacenters was set to zero seconds. The "gc_grace_seconds" attribute is not just used as the time for removal of tombstones, it's also used to set the TTL for records written to the system.hints table. That meant that when the hints were written for the ADM tables for the nodes that were down, they were immediately expired since it was set to 0 and not played back when the terminated nodes restarted and joined the cluster. This has been resolved with this fix for all customers new to this release. Existing customers already on v7.3 or higher will need to complete the local change detailed below: Connect to the Cassandra cluster using cqlsh in the Pega Cassandra distribution and then run ALTER TABLE adm_commitlog.adm_response_commit_log_date_tiered WITH gc_grace_seconds = 86400; to change the relevant setting from zero to the equivalent of one day - the same length of time that the data in the table lives for. This will mean that any hints written can still be used to replay data to another node while the data itself is alive. It does also mean, however, that, given a constant load, a day's worth of expired ADM event data in the table will always be present on the disk, as the tombstones can now not be cleaned up for a day.