Rules can no longer access Pega internal Java packages
Valid from Pega Version 8.4
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.
Changes to the architecture of the Data Flow service
Valid from Pega Version 8.4
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.
Limits on active data flow runs
Valid from Pega Version 8.5
You can now configure a maximum number of concurrent active data flow runs for a node type. Set limits to ensure that you do not run out of system resources and that you have a reasonable processing throughput. If a limit is reached, the system queues subsequent runs and waits for active runs to stop or finish before queued runs can be initiated, starting with the oldest.
For more information see, Limit the number of active runs in data flow services (8.5).
Upgrade impact
If you have many data flow runs active at the same time, you might notice that some of the runs are queued and waiting to be executed.
What steps are required to update the application to be compatible with this change?
You do not have to take any action. After the active runs stop or finish, the queued runs start automatically. The default limits are intended to protect your system resources, and you should not see a negative impact on the processing of data flows. However, if you want to allow a greater number of active data flow runs to be active at the same time, you can change the limits. For more information, see Limiting active data flow runs.
External data flow rules are deprecated
Valid from Pega Version 8.5
External data flows are now deprecated and no longer supported. To improve your user experience with Pega Platform™, the user interface elements associated with these rules are hidden from view by default. Identifying unused features allows Pega to focus on developing and supporting the features that you need.
For more information, see Deprecated: External data flows.
Visual Business Director data is automatically cleaned after a retention period expires
Valid from Pega Version 8.5
To avoid negative impact on system resources, such as memory and disk space, Pega Platform™ automatically cleans out collections data accumulated in Visual Business Director after the time period specified in the vbd/dataRetentionTimeout dynamic system setting.
Upgrade impact
In versions of Pega Platform earlier than 8.5, collections data was not automatically removed. From version 8.5, the data is removed after 465 days (15 months) by default.
What steps are required to update the application to be compatible with this change?
If the default data retention period does not meet your requirements, you can change it by editing the vbd/dataRetentionTimeout setting.
For more information, see "Configuring the data retention period for Visual Business Director" in the Pega Customer Decision Hub 8.5 Upgrade Guide on the Pega Customer Decision Hub product page.
Uploading customer responses into adaptive models is no longer available
Valid from Pega Version 8.5
The option to train adaptive models by uploading a static list of historical interaction records has been deprecated in Pega Platform™ 8.5.
Upgrade impact
In versions of Pega Platform earlier than 8.5, it was possible to train an adaptive model by uploading historical data of customer interaction. After the upgrade to version 8.5, this option is no longer available.
What steps are required to update the application to be compatible with this change?
Use data from a report definition to train adaptive models. For more information, see Training adaptive models.