SR-C25202 · Issue 365395
Fixed offline sync flow processing corruption
Resolved in Pega Version 8.1
In offline sync, only differences are sent from the device to the server for each action. The server-based sync service merges the differences onto the full work object read from the database. In some cases, data with blank values in the received different JSON was not replacing existing values in the workpage, causing corrupted flow processing and completed cases being returned to the application inactive queue. This was traced to a missed use case for pxObjClass while sending data from client to server, and has been resolved.
SR-C25312 · Issue 377871
New APIs added to get more precise broken process information
Resolved in Pega Version 8.1
Queue items related to a Service requester were going to broken status with a "Database rollback caused queue item rollback" exception instead of displaying the actual exception in the broken process queue. This has been resolved by adding new APIs to get errorMessage and stackTrace.
SR-C25312 · Issue 373512
New APIs added to get more precise broken process information
Resolved in Pega Version 8.1
Queue items related to a Service requester were going to broken status with a "Database rollback caused queue item rollback" exception instead of displaying the actual exception in the broken process queue. This has been resolved by adding new APIs to get errorMessage and stackTrace.
SR-C25312 · Issue 379465
Failed service requestors return status along with error message
Resolved in Pega Version 8.1
Queue items related Service requesters were going to broken status with a "Database rollback caused queue item rollback" exception. Investigation showed BatchRequestorTask was not returning error messages in case of failure on a service activity, but rather displayed a generic error message in all error scenarios. This has been fixed by modifying ProcessServiceRequestMethod to return the status of a service activity along with an error message in cases of queue process failure.
SR-C25321 · Issue 372748
Cleared checkbox param to ensure correct exported date/time
Resolved in Pega Version 8.1
When a report definition was configured to display a datetime property with column format as DateTime and DateTime format as "01-Jan-2011 1:00:00 AM EDT" is displayed in report viewer as "09-Apr-2018 02:20:00 PM EDT" (12hr format), the date showed as "09-Apr-2018 14:20:00 EDT" (24hr format) when it was exported to a PDF. In this situation, the report viewer has a querytimestamp field which uses Data time as the control and has the display 24 hours format checkbox checked. This value was added to the parameter page and later was not cleared, causing the other data time fields also display in 24 hours format. To correct this, pzGenerateFormat RUF has been modified to clear this param at the end.
SR-C25564 · Issue 366809
Updated locales to properly use Other Currency option
Resolved in Pega Version 8.1
When the Currency control was configured to display "Other currency" symbol value and the property was populated with USD, the property is displayed as 100.00 / USD in the es_CR, es_GT and es_HN locale, but in local format only for the es_PA, es_NI and es_SV locales. This was an issue with the default Currency Symbol values for es_PA, es_NI, es_SV pointing to old ICU2 formats, and has been fixed by changing the currencysymbol attribute in es_PA.xml, es_CR.xml, and es_SV.xml.
SR-C25702 · Issue 370594
REST POST method sets Content-Type and Boundary
Resolved in Pega Version 8.1
When the REST Connector was set to use the JSON mapping mode for request data and a request attachment page was present, the resulting Multipart message contained the mapped JSON in the "PostData" Part, with the Content-Type header of the Part incorrectly set to "text/plain" rather than the correct value of "application/json." This meant that services consuming the request did not know to handle it as JSON. To fix this, the REST Connector engine module and HTTPClientUtils module have been retooled to match the details and also to handle binary content mapped in as base64-encoded string. This can be overridden via a parameter. The "fat channel" now accepts Part objects so that the Connector implementation can craft a Part with all aspects of the Part, rather than providing only a value. The feature has also been enhanced to better handle Multipart request/response cases.
SR-C25702 · Issue 369365
Fixed content-type in Multipart for PostData
Resolved in Pega Version 8.1
When the REST Connector was set to use the JSON mapping mode for request data and a request attachment page was present, the resulting Multipart message contained the mapped JSON in the "PostData" Part, with the Content-Type header of the Part incorrectly set to "text/plain" rather than the correct value of "application/json." This meant that services consuming the request did not know to handle it as JSON. To fix this, the REST Connector engine module and HTTPClientUtils module have been retooled to match the details and also to handle binary content mapped in as base64-encoded string. This can be overridden via a parameter. The "fat channel" now accepts Part objects so that the Connector implementation can craft a Part with all aspects of the Part, rather than providing only a value. The feature has also been enhanced to better handle Multipart request/response cases.
SR-C25746 · Issue 371903
Fixed logic in Decision Table evaluation logic
Resolved in Pega Version 8.1
If a decision table was created with more than 5 columns and more than 1000 rows, trying to evaluate lines 1024 to 1062 (1084 to 1122 etc.), even though those lines matched, resulted in an otherwise value instead of the actual row value. This was caused by a logic error, and has been fixed.
SR-C25788 · Issue 390394
Changed temp directory handling for Export to Excel
Resolved in Pega Version 8.1
In rare cases, using the Export to Excel feature on the report definition viewer resulted in a Java FileNotFoundException. This was traced to process conflicts between the new Export to Excel implementation first featured in 7.3 and the Apache POI used to generate Excel documents by streaming the file to the disk as it is populated. Each worksheet in the document is streamed to its own temporary file. At the end of generation, the Excel document is created by opening the completed temporary files and copying their data into the final document. This way the entire dataset is never held in memory at once unless it is particularly small. However, the temporary file that holds the Data worksheet was in rare cases being deleted while the rows and columns were being populated. This was not noticed by the code until the file was reopened to copy its data into the final spreadsheet. Since it is not necessary to store the temp files in a separate directory (poi files) instead of using the the default configuration for saving temp files, the system will now use the function PegaTempFileCreationStrategy which will create the temp file but not create the temp directory. This means all the generated temp files are stored directly in the temp directory and not in the sub-directory poi files. ExcelReportExporter has also been updated so Apache POI knows to use this class for managing temp files.