INC-159736 · Issue 630045
Queue processor alert threshold error resolved
Resolved in Pega Version 8.6
After upgrade from v8.2.6 to v8.5.2, all queue processors reported the error "Threshold Default - 2000.0 is not a valid integer value". The issue was related to Java type promotion from long to double; since the ClipboardPage.setValue() method has two overloaded versions accepting int or double, the double type was being selected for the long type and returning 2000.0 instead of 2000 for alertConfig.getThreshold(). This has been resolved by updating the system to specify setValue((int)alertConfig.getThreshold()) in the pzLoadQueueProcessorAlertDefaults activity.
INC-159879 · Issue 627830
Race condition resolved for input/output pipe streams
Resolved in Pega Version 8.6
Writing to S3 using file data set was failing with the error "Exception occurred while uploading file". The system was relying on PipedInputStream for getting the data from the file while uploading, which needs to be connected to PipedOutputStream which holds the data to be uploaded. Investigation showed a race condition was occurring where for some use cases the reading of inputStream was happening before the connection of I/P and O/P streams, resulting in a "Pipe not connected" error. This has been resolved.
INC-160103 · Issue 627602
REST connector creation errors resolved
Resolved in Pega Version 8.6
Attempting to create REST Connectors via the dev studio wizard using live endpoint invocation as "Add a REST response" was failing with a java.util.LinkedList error. This had a workaround of either running the REST wizard with file upload samples or configuring them directly on the rule form. In addition, REST Connectors were not executing if both the DEBUG level logging was turned on and the request had no headers, which had a workaround of using any other logging level (INFO, ERROR). These issues have been resolved by updating the system such that pyResponseHeaders are populated appropriately, and if there are no headers in the request, the system will not try to remove the trailing comma that would have been introduced in the oLog message.
INC-160360 · Issue 6256
Optimizing helper class enhanced to handle external databases
Resolved in Pega Version 8.6
Running a BIX extract that included a manifest for a target database was resulting in a null pointer exception for the manifest extraction. Attempting to generate the DDL for the manifest table also failed. This was traced to an issue with the helper class using a hardcoded default database for forming the queries, causing it to ignore the database config/DADN/prconfig for the Oracle database and form a query using the PegaRules' database credentials. This only occurred when trying to do external database operations on a different database platform; Oracle PegaRules worked as expected with an Oracle external database and Postgres Pegarules worked with a Postgres external database, but mixing Postgres PegaRules and an Oracle external database would result in the null pointer exception. To resolve this, the helper class has been enhanced to work with external databases by passing the database name as a parameter so it will properly calculate the query based on the type of target. An error in the name of the class has also been corrected, and is now available as PerformanceHelper rather than the previous "PerformaneHelper".
INC-160767 · Issue 628373
Email headers correctly mapped when using MSGraph
Resolved in Pega Version 8.6
The value of "Send Date" was not correctly populated when using MSGraph instead of IMAP, causing the Email Listener to fail. Microsoft populates the "sendDateTime" field in the JSON with the value of the RFC 822 email header "Date:", but this value was not being passed to Java object of type "Message" as part of the query. To resolve this, ReceivedDateTime and SentDatetime have been added in the select filter of getMessagebymessageID.
INC-162198 · Issue 628703
Tracelist cleared to address parser exception in REST Service
Resolved in Pega Version 8.6
In a requestor pool of mixed types, HTTP and REST, the alert data was not initialized properly if there was a parse exception due to invalid data in the incoming payload. For example, last_input, first_activity, and last_step could all be left over from the prior HTTP service request. This was caused by the system pulling in seemingly unrelated activities for the "Last activity called" in the stack trace of a service when a single alert was created by two different service types which were sharing the same package, and has been resolved by explicitly clearing the tracelist for the service to prevent inaccurate information being reported in the logs.
INC-162217 · Issue 635889
Default sorting with Pagination, Data Page and Report Definition corrected
Resolved in Pega Version 8.6
After configuring a section with the table sourced from a data page and personalizing the table with the pagination and sort-by features available in a report definition, the table content sourced with the data page was not sorting the data. This has been resolved by updating the pxRetrieveReportDefinition activity so that the sort order for queryable data pages will not be reset for a first-time request.
INC-163295 · Issue 631472
Cookie filtering logic updated to better handle upgraded environments
Resolved in Pega Version 8.6
After upgrade from Pega 8.3 to Pega 8.5, login issues were seen if cookie/HttpOnly was set to 'true' and the cookie was sent as part of headers based on the prconfig setting. This was due to handling changes, and has been resolved by updating the cookie filter logic.
INC-163791 · Issue 633298
JobScheduler time zone display expanded
Resolved in Pega Version 8.6
The Time zone control on the JobScheduler rule form displayed only the first few characters for the time zone. This was due to a hard-coded CSS setting for the width, and has been resolved.
INC-163863 · Issue 632427
Monthly agents run correctly on non-English locales
Resolved in Pega Version 8.6
Nodes with non-English locales were not starting when using an Agent with a monthly execution pattern. This was due to incorrect handling of the user locale, and has been resolved.