Published Release Notes

Data schema error on z/OS split schema upgrades from versions before Pega 7.1.8

When upgrading to a split schema on Pega 7.x with IBM DB2 for z/OS, you see an error during the data schema upgrade when the system tries to drop the PRPC_Updatescache procedure. Because triggers on rules tables use PRPC_Updatescache, you must use the ZOSDisableTriggerScripts to disable these triggers before you update the data schema.

1. Follow the instructions in the Pega 7 Platform Upgrade Guide to upgrade the rules schema, but stop immediately before you upgrade the data schema with the upgrade.bat or upgrade.sh script. The Pega 7 Platform Upgrade Guide is on the Support > Deployment Guides page.
2. Copy the contents of the <distribution>\ResourceKit\ZOSDisableTriggerScripts directory into the <distribution>\scripts\ directory.
3. Run fixZosTriggers.bat or fixZosTriggers.sh with the following arguments:
   --action preupgrade
--dataschema <data schema name>
   --oldrulesschema <old rules schema name. If you are upgrading from a single-schema system, this is the data schema name.>
   --newrulesschema <new rules schema name>
   --automaticddl <Optional. Set to true to automatically apply the disable trigger SQL scripts.>

   For example:
   fixZosTriggers --action preupgrade --dataschema pegadata --oldrulesschema pegarules --newrulesschema newrules --automaticddl false

4. If you did not set --automaticddl to true in the previous step, run the <distribution>\schema/disable.sql script to manually disable the trigger SQL scripts.
5. Run the data schema upgrade as described in the Pega 7 Platform Upgrade Guide.

Reports with visualizations of performance and automation levels for the email bot

In the Email Manager portal, you can now use built-in reports to visualize Pega Email Bot™ performance and the automation levels that are related to received emails, triaged cases, and created business cases. You can plug the reports to display the report data in other portals, for example the Case Manager portal. Based on the information displayed in the reports, you can adjust the machine learning models to achieve greater automation in the system.

For more information, see Viewing the reports for the Email channel and Built-in reports for the email bot.

Automatically update dependent applications to use the latest versions of built-on applications

You can now automatically update dependent applications to use the latest versions of built-on applications. When you import an archive that you created from a product rule, you can update all dependent applications to be built on the latest application versions in the archive.

For more information, see Updating dependent applications with the latest versions of built-on applications.

Improved experience when building an IVA and Email Bot in App Studio

Build your Pega Intelligent Virtual Assistant™ (IVA) and Pega Email Bot™ while working only in App Studio. This approach makes the design process easier and more intuitive, and saves you time. You can now modify the advanced text analyzer configuration while working in App Studio. In addition, if you have access to Dev Studio, you can edit the text analyzer rule from App Studio for your chatbot or email bot by clicking a link to open the settings in Dev Studio.

For more information, see Adding a text analyzer for an email bot and Adding a text analyzer for an IVA.

Triage cases archiving in the email bot (Pega Cloud Services)

For Pega Platform™ that is installed in Pega Cloud^® Services, you can configure Pega Email Bot™ to archive resolved triage cases that are older than a specified number of days. Archiving triage cases improves the overall performance of your system by reducing the primary storage consumption and cost because the system places such resolved triage cases in a secondary storage.

For more information, see Archiving resolved emails for an email bot (Pega Cloud Services).

Alerts for long-running queue processor and job scheduler activities

Pega Platform™ now saves an alert in the performance alert log when a queue processor activity or a scheduled job runs longer than the configured threshold value. Use the alerts to identify potential performance issues with long-running processes.

The alerts are enabled by default. You can change the alerts for dedicated queue processors and job schedulers at the rules level. For standard queue processors, you can also set the threshold value for the Queue-For-Processing command in an activity. You disable the alerts in dynamic system settings.

For more information, see:

• PEGA0117 alert: Long-running queue processor activity
• PEGA0118 alert: Long-running job scheduler activity

Usability improvements in the Email Manager and Case Manager portals

Pega Email Bot™ customer service representatives (CSRs) working in the Email Manager, Case Manager, or Case Worker portals can now quickly reply to one recipient or to all recipients. CSRs can also view the sentiment analysis of an email (positive, negative, or neutral) for each received email, displaying the sentiment pattern for the entire email thread in a triage case. The email bot improvements add value for CSRs working in the portals and help them save time when responding to user requests.

For more information, see Understanding the email triage process and Replying to customers by email for an email bot.

New JWT access token format: Authorized Access Token

Pega Platform™ is changing from using opaque tokens to using JSON Web (JWT) tokens and the JWT access token format: Authorized Access Token (AAT). An AAT enables a client application to validate the server for user permissions and authorizes a specific application to access specific parts of a user’s data.

The major benefits to using the JWT format are:

• The JWT is a self-contained token that has authentication information, expire time information, and other user-defined claims digitally signed.
• A single token can be used with multiple applications.
• The tokens are short-lived and can minimize damage if transport security is compromised, as the token signature is verified.
• As the token is verified with the signature, there is no need to verify against a database, thus reducing latency (usually important for Web APIs).

For more information, see Understanding authorized access tokens.

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.

Enhanced refresh token strategy

You now have more precise control over your refresh token expiration strategy. When a refresh token is enabled, you can choose to set its initial expiration based on the value provided by the IDP. The refresh token expiry can be derived from IDP’s session timeout when SSO is used with external IDP for user authentication in the authorization code grant flow. You can also specify a separate refresh token expiration strategy based on your use-case. 

These can be configured in the OAuth2 Client registration rule form.

For more information, see Enhanced refresh token strategy.