Published Release Notes

Anypicker control is now available

The new Anypicker control displays a drop-down list of values that you can group into expandable categories for faster browsing. To save time and improve search accuracy, the Anypicker control filters the available values based on the characters that the user enters.

For more information, see Adding an Anypicker control.

Anypicker control in a condition builder

The condition builder now uses the Anypicker control to categorize the entities, such as fields or when conditions, that your application compares at run time. As a result, you can create conditions in a simplified and accelerated way. You can also select fields that are up to four levels deep within field groups.

For more information, see Create conditions faster with an Anypicker control (8.4), Adding an Anypicker control, Defining conditions in the condition builder.

Rules can no longer access Pega internal Java packages

You can no longer create rules that access Java packages that reference internal APIs (syntax com.pega.platform.*.internal*). This change does not affect rules that access Pega public API packages.

If you encounter issues when running existing rules that reference internal Pega APIs, contact Pega Support.

Upgrade impact

After an upgrade to 8.4 and later, clients can no longer save new or modified rules that access Pega internal APIs; existing rules that reference internal APIs can still be run but cannot be modified. 

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

Following a software upgrade to 8.4 or later, clients can refactor existing rules into guardrail compliant rules. To find rules to refactor, run the validation tool from designer studio (Application > Tools > Validation) to identify what rules fail validation; failed rules that include the message "Test compilation failed : Illegal internal class reference : com.pega.internal.XYZ" can updated to reference appropriate APIs.

Support for the JSON Web Token Bearer grant type for accessing external APIs

You can now access external APIs by using the new OAuth 2.0 JSON Web Token (JWT) Bearer grant type, in an OAuth 2.0 authentication profile. To use the JWT Bearer grant type as a client assertion, source the JWT from an active SSO session, a token profile, or a property reference. You can use JWTs that you obtain during an OpenID Connect SSO in connectors, to achieve user impersonation flows, such as the On-Behalf-Of (OBO) flow. The OAuth 2.0 type authentication profile now also supports authentication of client applications by using Private Key JWTs.

Instances of the OAuth 2.0 provider are now deprecated. As a best practice, use the new, unified authentication profile configuration instead.

For more information, see Configuring an OAuth 2.0 authentication profile.

Upgrade impact

After an upgrade to Pega Platform 8.4 and later, Authentication Profiles can take advantage of the new JWT based OAuth 2.0 grant type and client authentication features. To take advantage of this and other new security features, you must update any existing Authentication Profiles formats must to use those in Pega Platform 8.4 and later.

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

Since these features are available only for profiles created in Pega Platform 8.4 and later, clients must open and then save existing 'Authentication Profile' instances to ensure that the configuration is compatible with the latest authentication formats.

Improved mobile app user experience

Pega Platform™ can now produce a better mobile experience through performance gains and flexible access settings. Apps now support quick-loading native worklists, smooth scrolling and swiping, and query-based search, which improve productivity for mobile users. In addition, you can make your app available to users without authentication, and enhance usability for products that do not require strict security controls.

For more information, see Securing mobile apps.

Default support for skip links

All Pega Platform™ access groups now support skip links by default. Before, you had to create special access groups for users who require skip links for screen readers. Now, the feature is automatically enabled for every group, which improves the user experience and simplifies development.

Improved reliability of Visual Business Director

Improvements to the reliability of Visual Business Director (VBD) eliminate the impact of temporary access loss to the VBD cluster. The improvements include the ability to continue writing data to a VBD dataset while the corresponding server node is unavailable, enhancements to single-case data flows that write data to VBD, and a reduction in the VBD cache size.

For more information, see Eliminate the impact of temporary access loss to the VBD cluster (8.4).

Support for seamless transitions between IVAs and customer service representatives

To ensure the best user experience in chat sessions with a Pega Intelligent Virtual Assistant™ (IVA), customer service representatives (CSRs) can now step in and take control of a chat session multiple times, when the chatbot is not capable of correctly answering the user. After the user problem is resolved, the CSR can seamlessly switch control of the chat session back to the chatbot.

Custom activities protection

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.