INC-169544 · Issue 649541
Enhancement for MaxEnt modeling data
Resolved in Pega Version 8.7
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-126796 · Issue 561536
Modifications to getFunctionalServiceNodes process
Resolved in Pega Version 8.4.2
The count of the Interaction History write related threads was increasing rapidly and a stack trace indicated "waiting on condition" and "java.lang.Thread.State: WAITING (parking)" errors. Investigation showed that this was due to getFunctionalServiceNodes using Hazelcast to determine node status by making a service request on an installation with a very large number of nodes, causing thread locking. To resolve this, the implementation has been updated to avoid calling getFunctionalServiceNodes on save of Interaction History, instead using Cassandra and only calling getFunctionalServiceNodes on the master node, not on all nodes.
INC-139574 · Issue 606143
Exception handling added for dataflow rule assembly
Resolved in Pega Version 8.4.4
A Blue Screen error was coming up in the Customer Service Web Chat Application after an agent accepted the incoming chat request and sent messages in the chatbox in the Interaction portal. This has been resolved by adding handling for exceptions that occur when inlining templates during dataflow rule assembly, when inlining templates, we weren't handling exceptions properly.
INC-166561 · Issue 645648
ADM Models correctly updated
Resolved in Pega Version 8.7
The ADM models were not being updated when responses were processed either via the CaptureResponse API or when the time elapsed that should result in an update reflecting a non-response. This was traced to incomplete handling for a response coming for some other model which was converted to EMPTY, and has been resolved by modifying the logic so that the default responses and other responses are processed properly.
INC-191554 · Issue 681351
Mapping updated for Primary filter rule with globally optimized strategies
Resolved in Pega Version 8.7
A discrepancy was seen in the results when compared between running globally optimized strategies (GOS) and a normal strategy in the Customer Decision Hub. Investigation showed this was caused by a proposition filter rule containing When rules configured with the keyword "Primary", which caused page mappings to fail in GOS. This has been resolved by explicitly populating the primary context for callWhen.
INC-133169 · Issue 572613
Service Registry heartbeat updates
Resolved in Pega Version 8.4.2
If a service (node) did not update its heartbeat for more than 90 seconds, eventually these stale services were removed from the database because the service registry did not consider them present. To resolve this, topology listeners will now use a java thread pool to run their logic and no longer use the heartbeat thread. Even if these listeners are slow, it won't affect the heartbeat and won't cause nodes to become unhealthy. If for some reason the heartbeat becomes slow (due to database issues) it will issue a thread dump to help identify what causes the slowness and aid in troubleshooting.
INC-134097 · Issue 574512
Service Registry heartbeat updates
Resolved in Pega Version 8.4.2
If a service (node) did not update its heartbeat for more than 90 seconds, eventually these stale services were removed from the database because the service registry did not consider them present. To resolve this, topology listeners will now use a java thread pool to run their logic and no longer use the heartbeat thread. Even if these listeners are slow, it won't affect the heartbeat and won't cause nodes to become unhealthy. If for some reason the heartbeat becomes slow (due to database issues) it will issue a thread dump to help identify what causes the slowness and aid in troubleshooting.
INC-165704 · Issue 639506
VBD data flow timeout increased and made configurable
Resolved in Pega Version 8.7
Intermittent VBD timeouts were seen when writing records to MSK even though no errors were reported on the MSK side. Analysis showed that while batch data flows retry when a timeout occurs, real time data flows do not retry and the configuration to wait up to 10 seconds for an acknowledgement may not be sufficient depending on the system conditions. This has been resolved by increasing the default timeout to 20 seconds and adding a configurable timeout "vbd/streamPublishTimeoutMillis" to allow a customized setting.
INC-157097 · Issue 619995
REGEX In Expression Builder matches runtime values
Resolved in Pega Version 8.4.4
An expression builder statement was evaluating differently at runtime vs at testing. This was traced to a difference in escape character handling between old legacy code and the new strategy runtime engine, and has been resolved by ensuring the strategy runtime engine is supporting escape character use cases.
INC-187520 · Issue 677873
Actuals sync clears data from cache and persistence
Resolved in Pega Version 8.7
When sync attempted to clear the existing data from Actuals before copying data from the interaction history, the partition was cleared from the cache but not from persistence. IH data that was then copied to the same partition time ranges had new field descriptors created that did not match the format of the old data in persistence. As a result, when a query triggered the loading of such a partition, the mix of data with the old and new formats caused the load to fail. This has been resolved by updating the system to ensure the data is deleted properly from both the cache and persistence.