Published Release Notes

Role-based workspaces improve productivity

You can now use workspaces to access role-based tools and features. By focusing on the tasks that align with your expertise, you can develop and manage your application more quickly.

For more information about the different types of workspaces, see Workspaces.

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.

Improved identification and handling of code assembly errors

Code assembly error logs are now more meaningful and help you identify root causes with better accuracy. Pega Platform™ now also invalidates erroneous assembly to facilitate successful reassembly when the code is accessed again. For example, if a section is not correctly assembled when a user first signs in to the system, the application attempts to reassemble that section the next time a user signs in. In this way, you can avoid lingering issues and improve stability.

View data type relationships in Data Designer

You can now access a visual depiction of the relationships among data types from the Data Designer in App Studio. By understanding how data types depend on properties and other data types, you can extend your data model more quickly.

For more information, see Viewing data relationships.

Resolve Job Scheduler and Queue Processor rules with the AsyncProcessor requestor type

Use the new AsyncProcessor requestor type to define a default dynamic context to resolve background rules such as Job Scheduler and Queue Processor rules. Switch to an application-based context after you create your own access groups, to resolve only the rules that are included in your application.

For more information, see AsyncProcessor requestor 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.

Manage and visualize application data with the Integration Designer

Use the Integration Designer to manage data at the application level and to access a comprehensive view of all data objects in your application with their associated data. Additionally, from the Integration Designer, you can create data objects and map them to other objects and to systems of record.

For more information, see Managing application data with the Integration Designer.

Hierarchical table overhaul

The hierarchical table layout now uses a redesigned architecture that enhances stability and presentation. This update also improves accessibility by implementing ARIA guidelines and introducing keyboard navigation in tables.

For more information, see Creating a hierarchical table layout.

Response timeout configuration for predictions

You can now set a response timeout for your predictions in Prediction Studio. By setting a response timeout, you control how Prediction Studio registers customer responses that later serve as feedback data for your predictions.

For more information, see Customizing predictions.

Support for native search in custom mobile apps

To improve the overall user experience in a custom mobile app, you can configure native search in the user interface of the application. To use the search capability, first configure the pySearchConfiguration rule. This rule allows you to optionally define a set of search categories as a local data source. You then configure the mobile search action for any user interface control, for example, a button in a section. Users can tap the search field to see the most recent search results, including results that are grouped by categories, as they enter search text.

For more information, see Native search capability in custom mobile apps and Configuring search in custom mobile apps.