Published Release Notes

Integrate your application with external Kafka clusters

Configure your application to use an external Kafka cluster for managing real-time data. By having an external Stream service provider, you can perform such maintenance tasks as an upgrade or hotfix deployment faster because external nodes do not require restarting.

For more information, see Externally managed Stream service.

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.

Updated architecture of the data flow service

Benefit from improvements to data flow architecture that increase the stability of data flow runs and minimize the need for manual restarting of data flow jobs. Real-time data flows now use improved node rebalancing for better handling of failed or restarted nodes. If the topology changes, batch data flows no longer attempt to pause and resume the run. As such, there are fewer interactions with the database and between the nodes, resulting in the increased resilience of the Data Flow service.

If you are upgrading from a previous version of Pega Platform™, see Changes to the architecture of the Data Flow service for an overview of the changes to the Data Flow service compared to previous versions.

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.

Improved indexing performance by gradual retrieval of data

Search functionality in Pega Platform™ versions from 8.4.5 to 8.6 now includes the option to improve indexing performance when reading query results from a large table in a database. For example, to load the recommended 50 records at a time, in the Pega-SearchEngine ruleset, create the indexing/distributed/fetchsize dynamic system setting, and set the value to 50.

Creating the fetchsize dynamic system setting ensures that your system does not crash while indexing classes with numerous instances.

For more information, see Creating a dynamic system setting.

Real-time event processing

Real-time event processing is a mechanism that can be used to analyze a high velocity stream of events entering the system and derive conclusions from them. It is possible to define metrics, measurements, and conditions under which subsequent trigger events are generated.

For details, see Real-time event processing.

End of support for form-based rule forms in Pega 7.1.9

Rule forms that are configured to render as forms are no longer supported in Designer Studio or end-user applications. Form-based configurations are found on custom rule types that were created in earlier versions of Pega 7 and are characterized by pop-up windows that are rendered externally from Designer Studio.

Reconfigure Pega 7 applications that use such rule forms by using standard harnesses and sections.

1. Open the class form.
2. Click the Advanced tab.
3. Select Harness from the Rule formmenu.
4. Create a new harness and new sections that implement the logic of the custom rule, using standard user interface layouts and controls.

Migrating custom rule forms to harnesses and sections offers the following benefits:

• User interfaces become HTML5 WC3 compatible and responsive to different screen sizes.
• User interfaces become cross-browser compatible, rendered consistently in Google Chrome, Mozilla Firefox, Apple Safari, and recent versions of Microsoft Internet Explorer.
• Rendering performance on modern browsers is dramatically improved.
• User interface pop-up behavior is eliminated; all windows are rendered inside Designer Studio and end-user applications.

End of support for Microsoft Internet Explorer 8 and quirks mode applications in Pega 7.1.9

In accordance with Microsoft’s announcement to discontinue support for Internet Explorer 8 in January 2016, Pega 7.1.9 does not support Internet Explorer 8, nor does it support non-HTML5 standard user interfaces.

You must upgrade to Microsoft Internet Explorer 9 or later or use Google Chrome, Apple Safari, or Mozilla Firefox. If you are using Internet Explorer 9 or later, you must turn off compatibility mode by accessing the Compatibility View settings.

Note the following:

• Pega 7.1.9 does not support user interface rules that are not based on HTML5 standards (rules in quirks mode).
• If you use applications that are rendered in quirks mode, which enables Pega 7 to correctly display and render non-HTML5 standard user interfaces, you must update them to standards-based HTML5 user interfaces when you upgrade to Pega 7.1.9 or later. Pega 7 provides automated tools to help you migrate your applications.
• Pegasystems Global Customer Support will not investigate or fix any Pega 7.1.9 bugs or support requests that are exclusive to Internet Explorer 8 or quirks mode user interfaces.

You can quickly identify which components of your application user interface are not HTML5 standards-based by clicking Designer Studio > User Interface > HTML5 Application Readiness.

Upgrading to Pega 7.1.9 and a newer browser offers the following benefits:

• These browsers are HTML5 and CSS3 compliant.
• New features are supported and existing features work as intended.
• The Pega 7 Platform user interface is displayed and rendered as intended.
• Browser security is enhanced.

If you have additional questions about browser support, see the Platform Support Guide or contact Pegasystems Global Customer Support.

Report Browser removed from Designer Studio

The Report Browser and Access landing page have been removed from Designer Studio. In Designer Studio, developers can create, edit, and test reports by using the Report Definition rule form.

The Report Browser is still available in the Case Manager portal.