Published Release Notes

Tomcat log files moved to work directory

For Tomcat application server users, the default path for PRPC logs has been changed to the "work" directory for Catalina. For example:

<tomcat>\work\Catalina\localhost\prweb

This directory can be cleaned up during administration. To avoid loss of files, you can redirect logging to a different directory after installation:

1. Navigate to the <tomcat-home>\webapps\prweb\WEB-INF\classes directory.
2. Open the prlogging.xml file.
3. Locate the "appender" definitions section that contains the "@{web.tmpdir}" string
4. Update the FileNamePattern values to point to the new directory.

For more details, refer to the “Change the default path to PRPC logs” section in the Tomcat installation guide for your database.

EAR support for JBoss EAP 6

PRPC deployment in JBoss EAP 6 as an EAR archive is now supported. 

If you need to deploy the JBoss EAR file, go to My Support Portal and submit a Support Request. GCS can assist you with the procedure.

Small distribution kit

A new “small” release distribution format for Maintenance Levels (ML) is now available, designed to significantly increase adoption via: 

• Minimal package size and faster download time
• Minimal install time via tactical changes to the upgrade implementation and process

This kit contains streamlined installers (both UI and command-line installers) and specialized error handling for ML updates (for example, a “small” kit will only work if an existing version of the same release is already installed). 

The kit assembly has also been automated, which includes the construction of a PRPC_Rules.jar archive containing cumulative rules since the GA release. 

A “small” kit will work for any prior ML release within a major release (for example, the “small” ML5 distribution kit will update any customer on 7.1 ML1 through 7.1 ML4).

Improved data page performance

Improvements have been made with queueing and processing of asynchronously-loaded data pages to reduce the number of calls to the database and avoid generating performance problems because of unneeded asynchronous requests.

Real-time pulse processing for multinode systems

Multinode development environments now use real-time pulse processing. Previously, when a change was made on one node, the pulse processing interval could take a minute or more for that change to be reflected on another node. Now, when a rule is changed on one node, that change is immediately reflected on all the other nodes in the cluster. This change helps to ensure that users are running a rule on the same node as where the rule was changed.

Verifying that a Pega 7 Platform instance is running

You can verify whether a Pega 7 Platform instance is up and running by entering this URL: http://<<hostName:port/contextName>>/PRRestService/monitor/pingservice/ping

The Pega 7 Platform Engine responds with HTTP Response Code 200 if the instance is available. The response contains JSON text in the format { "duration":"<time in milliseconds>" }. Any other response codes or timeout indicate that the instance is unavailable.

Database storage used for passivation in High Availability mode

When an application is running in High Availability mode, the value attribute for initialization/​persistrequestor/storage in the prconfig.xml file or the Dynamic System Settings​ now defaults to "database."

Previously, applications running in High Availability mode required shared passivation, where either initialization/​persistrequestor/storage was set to “OnTimeout” or a custom passivation mechanism was used. The change to using database by default provides persistent storage for passivation, and provides control for the landing page for High Availability.

For more information, see Understanding passivation and requestor timeouts and the High Availability Administration Guide.

Support for Data streaming service for Pega Cloud Marketing 7.4 applications

Pega Cloud Marketing 7.4 applications support the Kafka-based Stream service featured in Pega Platform 7.4.