SR-C39791 · Issue 379314
Group processing and StartDate issues resolved for Timeline controls
Resolved in Pega Version 8.1
Two issues were seen in the Timeline control:Issue 1: When a technician was selected who had no events, the Technician was not shown in Y-Axis (Groups were not being displayed). A blank screen was shown instead. This was caused by the a condition where an empty datasource caused createDataset to return without processing groups. This has been corrected by adding handling so the system will initialize dsArray with an empty value if needed to ensure the group related processing takes place. Issue 2: The start range for Timeline was not respecting the StartDate given for the Events display. In this case, if either the start or end time was not available then neither was set. To resolve this, If an end date is not specified then it will be marked as the current date.
SR-D13388 · Issue 485169
Handling added for minor case creation errors
Resolved in Pega Version 8.2.3
When creating a case, if any step status failed due to a non-critical reason which did not impact case creation (for example, a mandatory parameter was missing from the data page), that failure state was propagated to SaveNew and ultimately to the case creation API. As a result of this failure report, no case ID information would be reported back to the requestor even though the case was created, and the API responded with status 500 - internal service error. This has been resolved by removing the StepStatusFail check from pzCreateCaseInternal so that non-breaking errors will not result in a 500 error, and a check has been added for page messages in svcAddWorkObject and svcPerformFlowAction so that validation messages are returned.
SR-C36091 · Issue 377696
Stuck run detection improved to give information and stop bad jobs
Resolved in Pega Version 8.1
When a run is in NEW state, attempting to trigger it caused the run to move into the INITIALIZING state and after some time back to the NEW state. Once that happens for the first time, it would continuously happen to the same run and force the creation of a new run. Investigation showed that in very specific situations a data flow run might take too long to initialize. That caused the system mechanism that detects runs stuck in a transitioning state to kick in and move it back to NEW state. Later that run would actually be initialized but its status would no longer be reported correctly, giving the impression that the run was always going from NEW->INTIALIZING->NEW. To prevent confusion, code has been to the stuck run detection that will add troubleshooting information and stop that run if it's in a state that was was not anticipated.
SR-D25607 · Issue 495622
Added NPE handling to PegaInstaller
Resolved in Pega Version 8.2.3
When upgrading, the error "Error: java.lang.NullPointerException [java] at com.pega.pegarules.deploy.internal.exposecols.jobs.ExposeWrapper.runExposer" appeared and the installation would not proceed. Investigation showed that the NPE occurred because of class name validation not being performed at the right place. As the NPE occurred in the main class, it initiated thread pool executor shutdown. However, the consumer pool did not shutdown because it did not receive the correct specific producer message fto do so. This has been resolved by ensuring isValidClass is executed at the right place in ExposeWrapper.java to handle the NPE, and adding handling for the interrupt exception in consumer thread so that in case of any run time exceptions in the main thread, the consumer thread will not be stuck.
SR-C48633 · Issue 390528
Missing rules will be inserted into pr4_rule_vw table
Resolved in Pega Version 8.1
On running ExposeCols from prpcutils, if pr4_rule_vw table was truncated or had some rules missing, then the records were not being updated. Logging indicated there were view rules which were present in pr4_rule_vw but not present in the actual class, causing a duplicate key exception when the system tried to insert the same rule again into the pr4_rule_vw table. Previously, ExposeCols functionality always updated the rule record and its corresponding Data-Rule-Summary record but would never insert a new rule or Data-Rule-Summary record. This meant that if the pr4_rule_vw table was truncated before running the column expose, none of the rows were getting updated as the table was empty. To resolve this, if the rule is missing in the pr4_rule_vw table, insert queries will be executed and the rule will be populated in the corresponding Data-Rule-Summary record.
SR-C6567 · Issue 352049
Enhancement added to customize Cassandra consistency level
Resolved in Pega Version 8.1
Inconsistent results were seen when the Cassandra database was queried from the Connect-Cassandra integration connector ruleset. During the queries, data is collected from different systems and loaded into the Cassandra database. If there is a distributed architecture, there is a risk that not all replicas will receive all the insert/updates at the time of the data load for any number of reasons (node down, node overwhelmed, network, etc.).With the default of consistency level 1, the Pega Cassandra query may hit a node that is missing the data requested. However, consistency level 2 forces Cassandra to read matching data from two nodes and in the background will perform a read repair on the node that is missing data. In order to enable the setting of a preferred consistency level for all connectors and for all operations, a new single DSS setting has been introduced: RS: Pega-BigData purpose:connector/Cassandra/consistency available values: " ALL ANY EACH_QUORUM LOCAL_ONE LOCAL_QUORUM LOCAL_SERIAL ONE QUORUM SERIAL THREE TWO"