Published Release Notes

Derby databases are no longer supported

Previously, an embedded Derby database could be used as a file system. This setup was configured by setting storage/class/<<filesystem>>/type to "embedded" in the prconfig file.

After upgrading, storage types that are specified as "embedded" now default to the local file system.

Service responses in HTTP and REST connectors are no longer modified

The Pega 7.1.8 release correctly leaves form service responses for HTTP and REST connectors unmodified. Upgrade to this release if you experience a problem in Pega 7.1.7 where service responses for HTTP and REST connectors are modified when the declared type in the Content-Type header is application/x-www-form-urlencoded. In this case, the responses were modified to a base 64 representation of the bytes in the string. In Pega 7.1.8, responses of type application/x-www-form-urlencoded are mapped to the property designated on the Connector record.

Configuration required for data operations on external schema when using a Postgres database

When you use the API for data operations on external schema in the Postgres database, you must update the prconfig.xml file. No other platform requires a prconfig.xml update.

To update the prconfig.xml file:

1. Stop the server and add the following entry to the prconfig.xml file:
   env name="database/databases/postgres_ext/defaultSchema"
   value="externalschema"
   where postgres_ext is the external database that uses the external schema “externalschema”.
2. Restart the server.

IMAGE data type replaced by varbinary(max) in SQLServer

Because Microsoft is discontinuing support for the IMAGE data type, the Pega 7 Platform now supports the varbinary(max) data type, which will replace the IMAGE data type. All new columns in existing tables and all new tables will use the varbinary(max) data type instead of the IMAGE data type, and IMAGE columns will be automatically converted to varbinary(max).

Atom Server and SOAP Server rule forms are deprecated

The Atom Server and SOAP Server rule forms are deprecated. Use the Connect CMIS rule form instead.

Existing rules that were created with the deprecated forms still work, but you cannot create new ones.

Pega File Listener process changes

Beginning with Pega 7.2.2, File Listener processes files in a different way:

• File movement in directories – Previously, files were processed from the Work directory. In Pega 7.2.2, files are processed from the source location. Files move to the Work directory only if the initial processing fails and Recovery is disabled.
• New file processing – Previously, File Listener would process all files in the source location, even if the files were added during the processing. In Pega 7.2.2, files added to the source location during processing are read the next time the File Listener starts.

For more information, see File Listener data instances.

Functionality of the pyInvokeRESTConnector rule and the pxDeferenceEndpoint rule moved to core engine

The functionality of the pyInvokeRESTConnector rule and the pxDeferenceEndpoint rule has been moved into the core engine code of the Pega 7 Platform. This change provides more consistent behavior, reduces maintenance, and reduces the risk of regression issues. As a result, you can no longer customize these rules, and upgrading the Pega 7 Platform requires special considerations if you previously customized these rules.

For more information, see Upgrading with customized pyInvokeRESTConnector and pxDeferenceEndpoint rules.

Customizations to the prlogging.xml file must be manually ported after upgrade

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

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.

Log file description in web.xml incorrect after upgrade to Apache Log4j 2

As a result of the upgrade from the Apache Log4j 1 logging service to the Apache Log4j 2 logging service, it is recommended that you update the log file description in the web.xml file from location of prlogging.xml file to location of prlog4j2.xml file. The description indicates which log file is in use. Updating the description avoids confusion about which log file is current. Change the description as shown in the following example.

<resource-ref id="ResourceRef_5">
<description>location of prlog4j2.xml file</description>
<res-ref-name>url/pegarules.logging.configuration</res-ref-name>
<res-type>java.net.URL</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>