INC-155294 · Issue 626663
Enhancement added for attachment size handling with Kafka
Resolved in Pega Version 8.5.3
Attempting to send an email attachment larger than 2 MB resulted in the error "Caused by: org.apache.kafka.common.errors.RecordTooLargeException: The message is 8101592 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration." This has been resolved by updating the Stream SPI size to 2.0.5-14 to support custom producer configurations. The settings can be passed as environment parameters, for example 'Dstream.producer.max.request.size=500990'.
INC-174652 · Issue 654140
Case Archive updated to better prune email and attachment metadata
Resolved in Pega Version 8.7
After configuring pyPegaArchiver, pyPegaIndexer and pyPegaPurger to remove old cases, there were no records present in the pr_metadata table but the records related to Data-Corr-Email, Data-WorkAttach-File and Link-Attachment remained. As there is no harm in removing these entries because the system has already copied the reference to these attachments, the entry in pr_metadata can be removed without any issue. With this update, external and shared entries now get removed from pr_metadata table when a purge is performed, however they do not get removed from the target table.
INC-173436 · Issue 648821
Performance improvement for Application Save: Node Level Data Pages
Resolved in Pega Version 8.7
As part of new functionality introduced in 8.3, data types defined in the application record will be turned into data objects on Application save. As part of this process node level pages are invalidated and reloaded and there is an explicit commit that marks the Application record as dirty and sends any calls for the application record to the database for fresh records. In a multi-node environment, the number of queries to get the application record being saved became exponentially higher and performance impacts were seen. This has been resolved by updating the system to skip eager loading of the data page definition when an access rule or application definition is saved.
INC-192979 · Issue 678361
Performance improvement for Application Save: Node Level Data Pages
Resolved in Pega Version 8.7
As part of new functionality introduced in 8.3, data types defined in the application record will be turned into data objects on Application save. As part of this process node level pages are invalidated and reloaded and there is an explicit commit that marks the Application record as dirty and sends any calls for the application record to the database for fresh records. In a multi-node environment, the number of queries to get the application record being saved became exponentially higher and performance impacts were seen. This has been resolved by updating the system to skip eager loading of the data page definition when an access rule or application definition is saved.
INC-185266 · Issue 676581
Index table correctly populates after migration
Resolved in Pega Version 8.7
After creating a product file with work instances, only some records were populating in the index-workpartyuri class through index rule. Investigation showed that if the IDs specified for the Work Range started with the same digits as were seen after the case prefix (e.g. W-1, W-1000, or W-22, W-2201) then only the indexes for cases that start with W-1 or W-22 were included in the export. This was traced to a step in AddPartyIndexWhenCondition where the EstimatedWorkPrefix local variable was calculated: the java step extracted anything that was the same from the start of the To and From range without taking into account the possibility that some digit characters after the "-" could be the same. To improve the accuracy of the prefix estimation, "-\d" will be used to make an educated guess.
INC-239902 · Issue 628577
Handling added for multi-file upload of duplicated files
Resolved in Pega Version 8.7
Attaching the same file multiple times during a single upload caused some of the duplicated files to not be included. The issue was not seen when attaching the same file multiple times but in different attempts. The exception "Can't continue with file attachment. FileData.xlsx is missing and might have been quarantined by anti-malware software" was logged. This was caused by the files being uploaded without updating filenames to have a unique ID, so multiple files with the same name were overwriting the previous file. This has been resolved by setting the appendUniqueIdToFileName parameter to true in the upload request so each copy of the filename is treated as an individual file.
INC-152647 · Issue 609605
Email Listener auto-reply evaluation updated
Resolved in Pega Version 8.5.3
After upgrade, messages were being read but not getting processed for a specific Email listener (RCEmailListerner). The error "Email flagged as an autoreply email and will not be processed" appeared in the logs. Previously, an email was not considered to be an auto-reply only when the 'auto-submitted' header didn't exist or existed with value 'no'. This caused issues with auto-forward or auto-redirect emails where 'auto-submitted:auto-generated' could be in the header. Due to this, email was marked as auto-reply and email listener stopped processing it. To resolve this, the system has been modified to mark the message as auto-reply if it finds 'auto-submitted: auto-replied' in the header, but not 'auto-submitted:auto-generated'.
INC-157081 · Issue 623806
Email Listener auto-reply evaluation updated
Resolved in Pega Version 8.5.3
After upgrade, messages were being read but not getting processed for a specific Email listener (RCEmailListerner). The error "Email flagged as an autoreply email and will not be processed" appeared in the logs. Previously, an email was not considered to be an auto-reply only when the 'auto-submitted' header didn't exist or existed with value 'no'. This caused issues with auto-forward or auto-redirect emails where 'auto-submitted:auto-generated' could be in the header. Due to this, email was marked as auto-reply and email listener stopped processing it. To resolve this, the system has been modified to mark the message as auto-reply if it finds 'auto-submitted: auto-replied' in the header, but not 'auto-submitted:auto-generated'.
INC-152057 · Issue 621210
S3 attachment migration handles LInk-Attachment with multiple instances
Resolved in Pega Version 8.5.3
After S3 attachment migration, some attachments were intermittently not opening and displaying an error relating to being unable to load the file. Investigation showed that the attachments that failed to open did not have a pxStorageType tag in the XML of the work item. After the migration is done, the corresponding Data-WorkAttach-File and Link-Attachment instances are updated to point them to the repository. In this case, multiple LInk-Attachment instances were pointing to the same Data-WorkAttach-File instances, so only one Link-Attachment was updated and all of the other instances pointing to the same Data-WorkAttach-File instance were rendered unusable. While there was a workaround of manually updating the storage type in the database, this has been resolved by updating "pzgetattachmentcontent","pzupdatesourcereferences", and "pzuploadcontenttoexternalstorage" to check whether attachment is already migrated or not using the boolean parameter "isAttachmentAlreadyMigrated" to ensure all of the other Link-Attachment instances for a particular attachment are updated. If a migration was done and all Data-WorkAttach-File instances are pointing to a repository with some Link-Attachment instances not updated, those will be updated by running the migration again.