Published Release Notes

Improved offline support for mobile apps

The updated offline mode in Pega Platform™ now reduces implementation time, enhances the development process, and helps you create a more comprehensive mobile experience for users without a reliable web connection.

The improved offline support includes the following enhancements:

• Offline-enabled apps now use native mobile UI components, such as headers and bottom bars.
• Offline mode now supports decision trees for improved case processing. 
• Users can now process multiple cases simultaneously in separate offline tabs, which leads to higher productivity.
• Offline-enabled apps now work more efficiently because of improved caching and background synchronization.

For more information, see Working with offline apps.

Mobile features deprecated in 8.4

Following the introduction of new functionalities for mobile apps, some features are reaching end of life. To avoid additional effort during updates to future releases, do not use deprecated features.

In the 8.4 release, the following features are no longer recommended:

• Mobile Client 7 is now deprecated and planned for removal in 8.5. Use Pega Infinity Mobile Client to meet the mobile needs of your business.
• The Reuse existing web portal functionality is deprecated and planned for removal in 8.5. For improved app performance and more efficient development, use the mobile app builder in the mobile channel. Also, you must convert existing projects to use separate channels for mobile and web portals before upgrading to 8.5.

In addition, the Pega Mobile Express app has been removed from app stores and replaced with the Pega Mobile Preview app.

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.

Default views for cases and data objects

Pega Platform™ now generates default views for new case types and data objects. Because of this feature, your application now automatically creates a case summary and case details view for every new case type, and a list view for each data object. The default views automate a common recurring task, and improve productivity by reducing development effort.

Improved view authoring

Case authoring in Cosmos React UI now features updated view authoring tools. The redesigned view tab and overlay provide a more intuitive interface for creating views, applying design templates, and adding fields and controls. This enhanced work environment improves the user experience and reduces context switching, which contributes to a lower development effort.

For more information, see Editing views in a case type.

Enhanced tables in Cosmos React UI

The Pega Platform™ Cosmos React UI environment now includes improved tables. The updated tables use a revamped graphic design and support a number of new run-time behaviors, including column freezing and advanced filtering. The added features improve the user experience by giving case workers more control over data in tables, while the revised architecture enhances efficiency and reliability.

More intuitive portal authoring

Pega Platform™ now features an updated portal authoring interface that provides you with tools to edit landing pages, case pages, and portal settings all in one place. The interface also includes a live preview section that speeds up prototyping, encourages experimentation, and makes the authoring experience more user-friendly.

For more information, see Enabling Cosmos React UI for landing pages.