Published Release Notes

Mobile Settings tab in Designer Studio

The Mobile Settings tab in Designer Studio is used when wrapping a mobile application (app) to create a hybrid mobile app. Building an app using this process customizes the app's user interface displayed to users who access the app via the Pega 7 mobile app, available as a free download in the Apple iTunes and Google Play app stores.

This tab also provides fields for managing mobile app distribution, including using a QR Code to quickly access an application's URL and 

See How to build and brand a hybrid mobile application.

Tamper-proof Pega Web Mashup loading

To protect your application from hackers, Pega Web Mashup is now loaded in a more secure way. The system generates a channel ID in the mashup code for validation on the server, before passing the mashup request. 

For more information, see Creating a mashup.

Upgrade impact

After an upgrade to Pega Platform 8.5, existing mashups, which do not have the channel ID parameter in their code, cannot load and users see the access control warning.

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

If you need to maintain full availability of the mashup during the upgrade of the production environment, perform the steps in Migrating existing mashups.

Behavior changes when reporting on descendant classes

Report Definitions that use the Report on descendant class instances option with the Include all descendant classes option apply only to the Applies to Class. Join classes are not included as they were in previous Pega^® Platform versions. The following example shows what happens for each possible scenario for Report on descendant class instances when the report is defined on ClassA with a class join with Work-.

• If Report on descendant class instances is disabled, the report runs against ClassA and the join happens with Work-. The behavior is the same in Pega 7.3.1 as it is in previous Pega Platform versions.
• If Report on descendant class instances is enabled, and Include single implementation class is selected, the report runs against ClassA and the join happens with the MySampleClass implementation class. The behavior is the same in Pega 7.3.1 as it is in previous Pega Platform versions.
• If Report on descendant class instances is enabled, and Include all descendant classes is selected, the report runs against ClassA and its descendants and the join happens with Work-. In previous Pega Platform versions, the join happened with the MySampleClass implementation class.

Automatic separation of date input

Date fields in Date Time controls now automatically divide strings of input into days, months, and years. In single fields, the system adds slashes (/) as the user types the value. For example, an input string of 10102020 becomes 10/10/2020. In separate day/month/year fields, the system automatically switches from one field to the next as the user types the value. This enhancement improves the user experience by helping to users provide input in a more convenient and time-efficient manner.

For more information, see Configuring a Date Time control.

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.

Improvements to OAuth 2.0 Services with Token Introspection Service and Token Denylist Service

Increase the security of user sessions by using the newly supported Token Introspection and Denylist services for OAuth 2.0.

Token Introspection service

Use the Token Introspection service to validate JSON Web Tokens (JWT). The Token Introspection service requires authentication. 

Pega now uses OAuth 2.0 access tokens called Authorized Access Tokens (AAT). 

Token Introspection service endpoint

The Token Introspection service endpoint provides the information about the status of access token and refresh token. Token introspection can be used to validate if a given token is still active or inactive. The token introspection endpoint determines whether the token is valid. The status indicates whether an access token or refresh token is valid or invalid: 

• Valid tokens have the “active”:true status
• Invalid tokens have the “active” :false status.

The inactive status can also be due to revocation. 

Token Denylist service

You can add tokens to the deny list in cases where suspicious activity might have occurred. The Token Denylist service provides a method for denying user access to the application by revoking the user's access token. This service can prevent a token from being used more than the specified number of times, which can be helpful in preventing replay attacks. Stolen tokens should be revoked using this service. A GET API is also available to get the list of denied tokens.

Keys endpoint

Pega Platform™ is changing from using opaque tokens to JSON Web (JWT) tokens. If this JWT is used by any other system, the public key is needed for signature verification. A new endpoint is exposed to provide these public keys in JWK format: https://host:port/prweb/api/oauth2/v1/token/keys.

For more information, see OAuth 2.0 Management Services.

Custom activities protection

Enable users to save charts as .png files

You can now enable users to save a report chart as a .png file. On the Chart tab of the Report Definition rule form, click General settings and select the Export chart to image check box. When you select this option, users are provided with the Save as image option, which they can use to save an image of the chart to include in a Word document or email.

For information about including a chart in a report, see Adding or editing charts from the Report Definition rule form.

Search and Reporting does not index large items

When using the Search and Reporting (SRS) microservice in Pega Platform™ 8.5, you might encounter problems with indexing large out-of-the-box rules. The issue is not visible in Queue Processors, but you can access logs to verify which items the system does not index.

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.