Published Release Notes

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.

Post files and links with pxPostMessage API

The pxPostMessageAPI now supports text messages, file attachments, and hyperlinks. You can programmatically update Pulse streams using this API from activities or SLA rules.

Case Management

This release has continued to focus on improving the functionality of the design environment with improvements to the Case Designer and stage configuration. Additional end user capabilities were also added to allow for processing a wider variety of cases, for those with and without stages and improved bulk processing handling.

• Flow action processing now uses the primary page instead of the interest page when using case/stage local actions, so that embedded flows are properly populated.
• Case-wide local actions rely on pzInternalStageFlow when there are no active, non-hidden assignments on the case. These case-wide local actions will now appear on a stage-less flow with no assignments.
• If a (valid) error is displayed in the outline view, saving or clicking around will not delete the error - the error will remain as a reminder to the developer to solve whatever problem is being flagged.
• May now add Cascading Approval validation and edit the parameters from the Case Designer Stage and Step page.
• Page labelling ("Page 1 of X") appears in the history list presented in the audit tab.
• The bulk processing feature has been enhanced.
• The Outline View functionality was changed so that the visible page will no longer refresh each time a flow is edited.
• The Post value was added to the instructions text field, so data isn't lost between nodes in the outline View.
• When Assign to Operator or workbasket is included as a filter, the bulk processing gadget is supposed to get a list of assignments. The UI for the results was enhanced for assignments to include a column for instructions so that the different assignments on the same work item can be distinguished.
• When designing a case type’s stages, it is no longer possible to skip the last stage (by using the "skip stage when" setting). When creating or editing the last stage, developers may no longer set a skip when rule; if tried, the system will display a warning and prevent that. If a Skip When rule is set up for a stage, and then all the intervening stages are deleted so that this stage becomes the last stage, the warning will display, and the Skip When rule will not be visible. If another stage is then added after that, the Skip When rule becomes visible again.
• When one or more locked work objects are processed using the Process Selected Items button, the action will be performed on the selected work objects. If the action is successful, a green tick appears on the work object. If it is not successful, a red cross will appear.
• When the topmost RuleSet in the RuleSet Stack is locked, customers may now open up Outline View by clicking "Configure Process Details" and make exploratory changes to experiment. Because the RuleSet is locked, these changes may not be saved, but the experiment can be tried.

Create, Save As, and Specialization forms

The familiar “New” and “Save As” forms have been streamlined to make record creation faster and more intuitive. You can easily target a specific layer in your application stack, interactively define the record’s configuration and select only those circumstance definitions that make sense for your use case.

While the underlying behavior for creating a record is not new for this release, the redesigned UI of these forms and new defaulting strategy for fields is worth noting:

To launch these forms, use one of the new options found in the action area of the form header:

Note that not all record types support the ability to specialize by circumstance.

For more guidance on how to use the Create, Save As and Specialization forms, please refer to: Intuitive record creation and specialization

Quickly create ad-hoc cases

The My Cases work area on the Case Manager portal introduces a Quick Create feature that lets users create cases and assign tasks that are not included in the processing of business cases (instances of case types defined in the Cases Explorer).  For example, a manager can create a case and a task to set up a phone conference with her staff, or a reminder to enroll in an online seminar. Users can also set up a series of tasks to represent all they work they need to do to accomplish a specific goal.

Extended currency control

The currency control can now display a different currency than the locale currency. This means a user in one country can view amounts that are designated in a foreign currency, using that currency's international conventions.  For example, a credit card transaction in Germany might need to be posted in US dollars. 

Responsive layout groups and grids

The Responsive UI was introduced in Version 7.1, and has now been enhanced in two areas, to create an entirely responsive UI.

PRPC 7.1.4 introduces the Layout Group control, which can render its contents as “tabs,” “accordions,” or as a “menu.”  The rendering choice is driven through the presentation layout (the skin), which presents the information responsively:  a “tab” at a certain breakpoint can turn into an “accordion” or a dropdown-style menu, depending upon what format would be most appropriate for the device/screen size being used.

The grid functionality has also been enhanced, so that grids may be displayed on a tablet or a phone without the need for horizontal scrolling, offering the optimum experience on a mobile device.  A PRPC Grid Layout now supports responsive breakpoints in the skin definition in which columns can drop off or be consolidated according to screen size.

Designers will be able to mark columns in the grid by importance, and at the first breakpoint, the columns marked as “less important” will be dropped off first.  At the second breakpoint, the grid turns into a “fat list,” with the most important column displaying as a heading for each item in the “fat list.”  Styling options can be associated with these breakpoints.