Published Release Notes

Updated default dynamic system setting for requestor pools

Clients can now enable or disable requestor pools for processing service requests using a new dynamic system setting called EnableRequestorPools with Pega-IntegrationEngine as the owning rulest. Previously, all deployments utilized requestor pools to improve service processing response efficiency; requestor pools eliminated overhead by automatically returning a requestor to the pool after it fulfills a service request. Starting in Pega Platform 8.4, requestor pools are disabled in Client-managed cloud deployments, since these deployments use autoscaling to handle service request traffic. Enabling requestor pools in Kubernetes environments is not recommended, because they can inhibit the default autoscaling settings in the environment.

Requestor pools remain enabled by default in Pega Cloud and on-premises environments.

To help clients navigate this change, Pega has updated its best practice guidance for configuring requestor pools. For an overview, see Requestor pooling for services. For guidance on the use of requestor pools in your application, see the EnableRequestorPools entry in Dynamic system settings data instances.

Upgrade impact

Requestor pools are disabled by default in Pega Platform 8.4 in client-managed cloud deployments. Clients who deployed previous versions of Pega Platform on a Kubernetes environment and who upgrade to Pega Platform 8.4 could see that their services behave differently.

What steps are required to update the application to be compatible with this change?

If clients that are deployed in a Client-managed cloud environment need to configure their services to use requestor pools and they understand how to configure requestor pools for their optimized use, these clients can re-enable requestor pools. Clients should review the best practice for configuring requestor pools before they re-enable requestor pools. To re-enable requestor pools, you modify the EnableRequestorPools setting in the Pega-IntegrationEngine Owning ruleset from “disabled” to Enabled [no value]. For details, see Editing a dynamic system setting.

Changes to the architecture of the Data Flow service

In Pega Platform™ 8.4, the architecture of batch and real-time data flows uses improved node handling to increase the stability of data flow runs. As a result, there are fewer interactions with the database and between the nodes, resulting in increased resilience of the Data Flow service.

If you upgrade from a previous version of Pega Plaftorm, see the following list for an overview of the changes in the behavior of the Data Flow service compared to previous versions:

• Responsiveness
• Updates to lifecycle actions
• Starting a run
• Triggering pre- and post-activities
• Selecting a node fail policy
• No service nodes and active runs

Responsiveness

Nodes no longer communicate and trigger each other, but run periodic tasks instead. As such, triggering a new run does not cause the service nodes to immediately start the run. Instead, the run starts a few seconds later. The same applies to user actions such as stopping, starting, and updating the run. The system also processes topology changes as periodic tasks, so it might take a few minutes for new nodes to join runs, or for partitions to redistribute when a node leaves a run.

Updates to lifecycle actions

To make lifecycle actions more intuitive, the Stop action consolidates both the Stop and Pause actions. The Start action consolidates both the Resume and Start actions.

You can resume or restart stopped and failed runs with the Start and Restart actions. The Start action is only available for resumable runs and continues the run from where it stopped. The Restart action causes the run to process from the beginning. Completed runs can only be restarted. If a run completes with failures, you can restart it from the beginning, or process only the errors by using the Reprocess failures action.

Starting a run

New data flow runs have the Initializing status, and start automatically. You no longer need to manually start a new run, so the New status is now removed.

If there are no nodes available to process a run, the run gets the Queued status and waits for an available node.

Triggering pre- and post-activities

The system now triggers pre-activities on a random service node, rather than on the node that triggered the run.

The system triggers post-activities only for runs that complete, fail, or complete with failures. If you manually stop a run with the Stop action, the post-activity does not trigger. However, restarting the run with the Restart action triggers first the post-activity, and then the pre-activity.

You can no longer choose to run pre- and post-activities on all nodes.

Selecting a node fail policy

For resumable runs, you can no longer select a node fail policy. If a node fails, the partitions assigned to that node automatically continue the run on different nodes.

For non-resumable runs, you can choose to restart the partitions assigned to the failed node on different nodes, or to fail the partitions assigned to the failed node.

No service nodes and active runs

If the last data flow node for an in-progress run fails, the run remains in the In Progress state, even if no processing takes place. This behavior results from the fact that data flow architecture now prevents unrelated nodes from affecting runs.

Email Wizard support discontinued

Pega Platform™ no longer includes the Email Wizard. This wizard helped set up an email service for sending and receiving email in Pega Platform. The wizard generated an email account, an email listener, and an email service rule.

After an upgrade to Pega Platform 8.4 and later, existing clients must create new email accounts and email channels in App Studio. When you configure a new email channel, you add your email accounts so that customers can send and receive email by using the Pega Email Bot. Configuration of an email channel automatically generates an email listener and service email rules.

For more information, see Creating an email account and Building an Email channel.

Addition of Servlet Management

Pega Platform™ now has Servlet Management in Pega Cloud® Services, which provides a simple and secure way to make changes to Pega Platform servlet definitions.

Servlet Management provides Pega Cloud Service clients with solutions to manage servlet configurations with self-service options. This reduces the cycle time for delivering configuration changes in Pega Cloud Service installations while also improving upgrade reliability. 

For more information, see Servlet management.

Upgrade impact

Clients with no application servlet customizations will not experience an impact. If you upgrade from Pega Platform version 8.5 or earlier and, prior to the upgrade, the Pega Cloud team provided your application servlet customizations, then following the upgrade, you must manually add, remove, or modify your servlet customizations in your upgraded application using this servlet management landing page in Pega Platform.

What steps are required to update the application to be compatible with this change?

To manually move your pre-upgrade servlet customizations as appropriate or add new ones to your upgraded application using the new servlet management landing page, follow the steps in Adding a servlet.

Upgraded selected third-party JAR files to support Pega Platform functionalities

Pega Platform™ 8.6 now provides upgraded versions of the JAR files that support various functionalities within the Platform, such as generating documents or PPTX files.

Upgrade impact

If you have custom implementations and use any classes from the upgraded JAR files directly in your code or through JAR APIs, after your upgrade to Pega Platform 8.6, your application might experience unexpected run-time behavior if the upgraded JAR version lacks any elements from the previous version. For example, custom implementations can typically include activities, functions, or non-autogenerated sections. Unexpected run-time behavior might also occur when you use a third-party library that has dependencies on the upgraded JAR files. If you use only default Pega Platform functionalities without any customizations, the JAR files continue to work correctly without any additional actions.

What steps are required to update the application to be compatible with this change?

If you have any JAR customizations, ensure that you test the upgraded JAR files for compatibility and upgrade impact. The following table lists the upgraded JAR files that might impact your application:

For more information, refer to the documentation of  your JAR provider.

Text predictions simplify the configuration of text analytics for conversational channels

Enable text analytics for your conversational channels, such as email and chatbot, by configuring text predictions that manage the text models for your channels. This new type of prediction in Prediction Studio consolidates the AI for analyzing the messages in your conversational channels in one place and replaces the text analyzer rule in Dev Studio.

Through text predictions, you can efficiently configure the outcomes that you want to predict by analyzing the text in your channels:

• Topics (ticket booking, subscription cancellation, support request)
• Sentiments (positive, neutral, negative)
• Entities (people, organizations, airport codes)
• Languages

You can train and build the models that predict these outcomes through an intuitive process, and then monitor the outcomes through user-friendly charts.

For more information, see Predict customer needs and behaviors by using text predictions in your conversational channels.

Upgrade impact

Channels that you configured with text analyzers in the previous version of your system continue to work in the same manner after the upgrade to the current version. When you edit and save the configuration of an existing channel, the text analyzer rule is automatically upgraded to a text prediction. The associated text prediction is now an object where you can manage and monitor the text analytics for your channel. When you create a new channel in the upgraded system, the system automatically creates a text prediction for that channel.

What steps are required to update the application to be compatible with this change?

1. Enable the asynchronous model building and reporting in text predictions through job schedulers that use the System Runtime Context (SRC) by adding your application to the SRC.
   For more information, see Automating the runtime context management of background processes.
2. Enable model building in text predictions by configuring background processing nodes.
   For more information, see Assigning decision management node types to Pega Platform nodes.

Deprecation of EAR deployments in Pega Platform 8.6

Starting with Pega Platform 8.6, EAR deployments of Pega Platform are deprecated. In the upcoming 8.7 release, EAR deployments will not be supported. The following rules that require EAR deployments will also be deprecated and no longer supported in Pega Platform 8.7:

• Connect EJB
• Connect JCA
• JCA Resource Adapter
• JMS MDB Listener
• Service EJB

With this deprecation, you can use the latest tools and keep your application up to date. 

Upgrade impact

In Pega Platform 8.6, you can still create rules that require EAR deployments and update existing rules. However, after an upgrade to Pega Platform 8.7, rules that require EAR deployments are no longer supported.

What steps are required to update an application to be compatible with this change?

To prepare your application for this change well in advance of the Pega Platform 8.7 release, see the following table for a list of alternative rules and for guidance on modernizing your application.

For information on the supported platforms that are affected by this deprecation, see Pega Platform 8.6 Support Guide.

Upgrading to Hazelcast 4.x requires downtime during upgrades to Pega Infinity 8.6

Upgrade impact statement

On-premises upgrades of Pega Infinity release 8.4.2 and later to version 8.5.1 or later on Tomcat and PostgreSQL are completed with near-zero downtime. However, upgrading to Hazelcast 4.x requires that you shut down and restart your application server.

What is required to update the application to be compatible with this change?

Hazelcast 3.x is enabled by default. For near-zero downtime upgrades, you do not need to perform any action.

For instructions about upgrading to Hazelcast 4.x, see one of the following topics:

• For near-zero downtime upgrades from Pega Infinity release 8.4.2 or later on Tomcat and PostgreSQL, see "Optional: upgrading to Pega Platform version 8.6: Upgrading to Hazelcast 4.x" in Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Tomcat and PostgreSQL.
• For all other upgrades, see "Optional: upgrading to Hazelcast 4.x" in the appropriate upgrade guide.

External data flow rules are removed

In previous versions of Pega Platform™, you could configure data flows to run in an external Hadoop environment. The external data flows functionality was deprecated and hidden from view in Pega Platform 8.5. The functionality has been now removed and is no longer available in Pega Platform 8.6.

For more information, see External data flow rules are deprecated.

Legacy Parse XML rule configurations must be upgraded to edit them

If your application has Parse XML rules that use the legacy configuration from Pega Platform™ 5.x, you cannot edit these rules after you upgrade to Pega Platform 8.6 until after you upgrade them to use tree-based parse rule configuration.

You must upgrade a Parse XML rule that you want to edit if it shows the following warning when you open it in Dev Studio.

This type of Parse XML rule is deprecated. An upgrade should be performed.

An option to upgrade also displays below the message.

Upgrade impact

Parse XML rules with the legacy configuration do not map data to the clipboard, and the rule definition is empty. After you upgrade to Pega Platform 8.6, you cannot edit Parse XML rules that you created in Pega Platform 5.x or earlier until you upgrade them to use tree-based parse rule configuration.

What steps are required to update an application to be compatible with this change?

Update legacy Parse XML rules to use tree-based parse rule configuration before you edit them in Pega Platform 8.6. Using tree-based parse rules is considered a best practice.

1. Open the legacy Parse XML rule.
2. On the Mapping tab, click Upgrade.
   Result: The Allow tree editing? check box is displayed and is automatically selected. You can add attributes and elements to the tree structure, or delete them.
3. Save the upgraded rule configuration.

For more information, see Parse XML rules.