Logging service now uses Apache Log4j 2
Valid from Pega Version 7.3
The Pega® Platform now uses the Apache Log4j 2 logging service. Apache Log4j 2 improves performance and provides support for all log file appender types. As a result of this upgrade, the prlogging.xml file has been renamed to prlog4j2.xml and the format of the file has changed considerably.
For details about the new file format see Pega Platform logging with the Log4j 2 logging service.
For new installations or for upgrades to systems that were using the default logging configuration, no changes are needed. For information about updating custom log files after upgrading, see Customizations to the prlogging.xml file must be manually ported after upgrade. For information about updating your socket server if you use remote logging, see Socket server has changed for remote logging. For information about updated the web.xml file after upgrading, see Log file description in web.xml incorrect after upgrade to Apache Log4j2.
Customizations to the prlogging.xml file must be manually ported after upgrade
Valid from Pega Version 7.3
As a result of the upgrade from the Apache Log4j 1 logging service to the Apache Log4j 2 logging service, the name of the logging configuration file has changed from prlogging.xml to prlog4j2.xml and the format of the file has changed considerably. If you customized your prlogging.xml file, port the customizations to the new prlog4j2.xml file. If you do not port the changes, the Pega® Platform uses the default prlog4j2.xml file and disregards your customized prlogging.xml file.
For more information about customizing your log files, see the Apache Log4j 2 documentation.
Socket server has changed for remote logging
Valid from Pega Version 7.3
As a result of the upgrade from the Apache Log4j 1 logging service to the Apache Log4j 2 logging service, the socket server that is used for remote logging has changed from the Log4j remote logging package with the LogFactor5 log analysis tool to TcpSocketServer. If you use remote logging, update your socket server to TcpSocketServer. For more information, see Installing and using remote logging.
Automatically process cases with SharePoint
Valid from Pega Version 7.3
You can now use Microsoft SharePoint Online to store and source case and Pulse attachments and to store and source attachments during automated case processing. Users only have to provide authentication and authorization details the first time they access SharePoint Online or when the trust has expired. The authentication profile must be OAuth 2.0 with a grant type of authorization code. The SharePoint Online component can be downloaded from Pega Exchange. For more information, see Downloading and configuring pluggable content management components.
Ability to set default values when importing data
Valid from Pega Version 7.3
You can now set default values for data that you import for a data type from a .csv file. By setting defaults, you can ensure that even when the .csv file data is incomplete, all of the data is imported. In addition, you can set default values for custom fields that do not have a matching source column in the .csv file. This feature is available for the Add and update and Add only import options. For mapped fields, the default value is used for new records if the source field is blank, and for existing records if both the source and target fields are blank. For custom fields, the default value is used for new records if a default value is provided, and for existing records only if the target field is blank.
For more information, see Importing data for a data type.
Ability to persist request data for synchronous REST Service failures
Valid from Pega Version 7.3
Request data can now be persisted when synchronous REST Service processing fails. To ensure that data is not lost and can be reprocessed, set the Execution Mode on the rule form to Execute synchronously (queue on error).
For more information see Service REST form - Completing the Service tab.
Create pluggable web storage components for case and Pulse attachments
Valid from Pega Version 7.3
You can now implement and post your own pluggable web storage components for use with case and Pulse attachments. These web components can be plugged in to Pega® Platform without the need to make changes to Pega Platform itself. The ability to create a pluggable web storage component is useful when you want to use a web storage provider that does not have an existing pluggable web storage component.
For more information, see Guidelines for creating pluggable components for storing and sourcing case and Pulse attachments.
Data Import wizard supports all Microsoft Excel default formats
Valid from Pega Version 7.3
The Data Import wizard for data types now supports all Microsoft Excel default date formats. Dates are easier to handle and you are alerted before data is imported if the date format is not supported.
For more information about supported date and time formats, see Date and time formats supported by the Data Import wizard for data types.
Fallback activity for Service REST and SOAP
Valid from Pega Version 7.3
You can now configure a fallback response activity for a time-out for Service REST and SOAP. Using a fallback response activity makes it easier to meet a service-level agreement (SLA) by providing a logical response in a timely manner. For example, the fallback activity can display a default offer to an ATM customer instead of an offer that is based on that particular customer's data.
For details about configuring the fallback response activity, see Service REST form - Completing the Service tab and Service SOAP form - Completing the Service tab.
Record Editor and data import enhancements
Valid from Pega Version 7.3
The Record Editor and Import wizard for data types have been enhanced to make the import process faster and easier to use. You can now perform the following tasks.
- Configure the Record Editor to use full-text search, which makes searching faster.
- Configure the location of the data import error file. For example, you can set the location to a shared location so that users can access the file from any node in a multinode system.
- Pass the keys of the records that were added, updated, or matched directly to custom postprocessing without additional database I/O.
- Search and filter records and export only the results instead of all records.
- Stop an import that is in progress.