INC-158686 · Issue 628554
DSS added to create consistent handling of longform datetime
Resolved in Pega Version 8.5.3
After upgrade, a difference in handling related to datetime value was seen. For example, EmailSchedRunEndDate is a date type property holding the value "20201016T000000.000 GMT"; in Pega v7.4, a substring function was used to move the extra characters from the date field ex. EmailSchedRunStartDate = @substring(.EmailSchedRunStartDate,0,8), but in Pega v8.4 and higher the long datetime value ( "20201016T000000.000 GMT") was still being used for the date field. This long value was then truncated to 2020101+ when saving to the database, causing errors in later steps. However, research found that if there is a call @toDate function before this step for any other field, the correct date value was set for EmailSchedRunStartDate. While ClipboardPages separate Dates and DateTimes, internally, in Java, both have a time component. The implementation of DSMClipboardPage made no difference for serialization and appended the time component for pure Date properties. To create consistent handling, an update has been made to optionally set the correct behavior after setting the Dynamic System Setting by way of "Pega-DecisionEngine dsm/clipboard/correctDateFormat -> true". This setting would only take effect after a restart of Pega, and the default is false in order to not disrupt any application inadvertently relying on this behavior.
INC-158813 · Issue 629486
Updated report handling for simulations using database output
Resolved in Pega Version 8.5.3
When running a simulation with a database table as the output destination, the pxObjClass property was not populating with a value in the results. This caused sub-reports to not be populated with data. Investigation showed that issue happened when the simulation output destination database table was inferred as an external table due to not having an exposed column for pzinskey. To resolve this, the pxObjClass and pxCreateDateTime properties, which were added to simulation output destination tables for compatibility with Report browser, will not be added to those tables when they are created. Instead, to address compatibility issues of simulation output destination classes with Report browse in the Customer Decision Hub, the pyDefaultSummaryReport has been brought up into the Data-Decision-StrategyExecution-ResultOutput class from the @baseclass.
INC-159332 · Issue 629619
Logic updated for finding 'Last' in Interaction History
Resolved in Pega Version 8.5.3
The 'LastReponseDate' and 'LastInteractionId' in the Interaction History summary data set were null. Investigation showed that reusing the ESM component in the aggregation dataset caused any assumptions made during the optimization of ESM to not be true anymore. To resolve this, the logic of the Last aggregation has been modified to not rely on a Last event which might not be stored in-state (such as optimization), but rather to use the list of events which is always stored.
INC-160277 · Issue 628160
Implementation updated to ensure consistent compareDatesByDays results
Resolved in Pega Version 8.5.3
When using compareDatesByDays in a filter shape within a strategy, the results of the expression were different between the expression test and the strategy test run. This was traced to a difference in handling that became visible after upgrade; giving a negative number for the numberOfDays parameter worked differently in v7.4 than in v8.4. The SSA implementation of compareDatesByDays always worked with the absolute difference in days between dates, whereas the Java function in Pega used in expressions did not, and would compare negative differences as well. To restore the expected behavior, the SSA implementation has been adjusted to not work with absolute differences, and tests have been added to ensure equal results for the Java function in Pega and the SSA implementation.
INC-160887 · Issue 629272
Resolved strategy optimization exception
Resolved in Pega Version 8.5.3
After upgrade from v8.2 to v8.5, Customer Decision Hub strategy failures were seen in the data join used with a datapage/page list to fetch some results. Errors appeared in the logs and UI. The exception indicated that the Strategy Parser for the new execution engine (SSA) was not able to parse and inline the used expression. Normally this exception would be caught in subsequent processing and the component where the exception is used would fall back to legacy so as to not affect the runtime behavior, but this scenario triggered a corner case inside the parsing logic for Data Join and Exclusion shape which caused the exception and stopped the process. To work around this issue, the Data Join configuration can be split into two shapes: create a new Data Import shape to only import the Page list, e.g. 'Page.pxResults', then on the original Data Join component, instead of joining the 'Page.pxResults', join with the new Data Import shape. This issue has been resolved by catching the exception when compiling the Data Join component and properly falling back to the Data Join shape.
INC-150317 · Issue 625883
Certificate updates handled across nodes
Resolved in Pega Version 8.5.3
An SSL handshake exception was occurring when running a Connect-REST call automatically from the flow as a background process on a background processing node. The same Connect-REST worked fine when run manually. The exception detailed the issue as "SSLHandshakeException: java.security.cert.CertificateException: None of the TrustManagers allowed for trust of the SSL certificate(s) provided by the remote server to which this client attempted a connection." This was traced to a pulse change scenario where the reloading of the certificates was not happening on all the nodes after adding a new certificate or deleting a certificate. This has ben resolved by adding the DATA-ADMIN-SECURITY-CERTIFICATE class into the UpdatesCacheUtils.java class.
INC-153957 · Issue 615290
Cache key handling updated for OAuth2 Connect-REST
Resolved in Pega Version 8.5.3
After upgrade, a Connect-REST using OAuth2 credentials was failing with HTTP response code 403 when the Connect-REST was invoked by the agent, but the Connect-REST was successfully invoked from web node with the same Auth profile. OAuth2 tokens are stored in the cache and database. In this specific environment the key formation was happening differently on the utility node for batch processes, causing different keys to be formed for the same token. This has been resolved by adding a provider filter and updating the cache key.
INC-154311 · Issue 615684
Decryption updated for External assignment routed with DWA
Resolved in Pega Version 8.5.3
When an external assignment was routed to a user using DWA, the user was able to access the assignment but received the error "There has been an issue; please consult your system administrator" when submitting. Investigation showed this was caused by the system attempting to decrypt the External assignment with the requestor level key, causing the decryption to fail with a NumberFormatException. To resolve this, the system will check if the obfuscated string starts with Global encryption key prefix and then decrypt with the global encryption key by trimming out the prefix.
INC-154627 · Issue 619571
Re-enabled users are able to log in
Resolved in Pega Version 8.5.3
When disabled operators were re-enabled through operator management, the forced password change on next login was manually unchecked but the operators were unable to login because the change password screen was displayed without any password entry fields. This was a missed use case for handling the change password flag on a requestor , and has been resolved by having the system skip setting the change password on next login flag for disabled users.
INC-155276 · Issue 626619
Null check added for step page
Resolved in Pega Version 8.5.3
After creating and adding new Access Roles and application 'Access When' to the privileges instead of Production level, during run time the error "runtime.IndeterminateConditionalException: Trying to evaluate Rule-Access-When conditions L:IsProdAccess when there is no page to evaluate them against" appeared for the specific privileges. This was traced to a missed use case where the system falls back to the step page if the page for evaluating the 'when' condition is null, which did not account for scenarios where the step page can be null. To resolve this, a null check has been added which will fetch the primary page if the step page for the access 'when' condition is null.