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.

DB2-LUW database logfile size increase

To avoid running out of logfile space due to large transaction sets during the rule base load of a Pega 7.1.x install, upgrade, or maintenance level update, systems supported by a DB2-LUW database platform should increase the LOGFILSIZ parameter to at least 4096 pages from the default size of 1000 pages.

After the size has been increased, restart the database to ensure that the new setting is loaded into the database correctly.

Need to run script before updating Multitenant systems

When updating or upgrading a Multitenant system from Pega 7.1.5 or 7.1.6 to Pega 7.1.7, if that system uses either an Oracle or a PostgreSQL database, you may encounter the error:

“Table must be empty to add column.”

The Multitenant architecture requires an additional column on a number of the PRPC database tables (“pzTenantID”). In Pega 7.1.7, two additional PRPC tables were tenant-qualified: pc_schedule_task and pr_index_schedule_task. The Multitenant column is added to these tables by the update/upgrade process. However, Oracle and PostgreSQL do not allow the addition of a non-null column to an existing table unless the table is empty, so updating or upgrading systems on those databases displays the error detailed above.

To avoid this error, before beginning the update or upgrade, it is necessary to run a script:

• Oracle — OracleMTupgrade.sql
• PostgreSQL — PostgresMTupgrade.sql

For updates, these scripts are located in the /scripts/ddl directory.

For upgrades, these scripts are located in the /Resourcekit/AdditionalUpgradeScripts directory.

Improved case auditing in App Studio

In Cosmos UI, App Studio now supports expandable case steps. This enhancement helps users quickly navigate a case and provides deeper insight into the case flow. In addition, Cosmos UI also introduces an improved history view that helps you better meet your business auditing requirements.

For more information, see Managing Cosmos UI settings in case designer.

Upgrade impact

After an upgrade to Pega Platform 8.5 or later, the history and chevron designs change automatically. However, applications with custom history settings might still display the styling that you defined in the override.

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

If your application uses custom settings and you want to use the updated history, remove the overrides from the pyWorkCommonActions rule.

Removal of Pega Mobile Client 7

You can now use a single Pega Mobile Client™ that improves app performance, app development, and meets all your mobile needs. With the introduction of new functionalities for mobile apps, Pega Mobile Client 7 is removed in Pega Platform™ 8.5.

Upgrade impact

After an upgrade to Pega 8.5, you can no longer build mobile apps based on Pega Mobile Client 7, and existing apps based on Pega Mobile Client 7 no longer connect to Pega Platform. App developers can now configure mobile apps with Pega Mobile Client.

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

Existing clients that upgrade to Pega 8.5 are automatically switched to Pega Mobile Client.

Limits on active data flow runs

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.

Failed Robotic Assignments work queue type changed to Standard

The default Failed Robotic Assignments work queue type is now Standard. In previous releases, the default type was Robotic. For usage information, see Configuring a work queue for robotic automation.

Upgrade impact

After upgrading to Pega Platform 8.5 and later, you cannot save case types in which you configure the Queue for robot smart shape to route new assignments to the Failed Robotic Assignments work queue. Existing assignments that you routed to the Failed Robotic Assignments work queue are not affected.

How do I update my application to be compatible with this change?

As a best practice, do not use the Failed Robotic Assignments work queue in your custom implementations. Instead, configure the Queue for robot smart shape to route new assignments to a Robotic work queue. When possible, update existing case types to use the robotic work queues that you created in your application.

Web portal reuse removed from the mobile channel

The reuse of web portals for creating mobile apps with a single web view is no longer supported. You can conveniently update your existing channels that reuse web portals to take advantage of the multiple-views experience and native mobile capabilities, such as native mobile list views or floating action buttons.

Upgrade impact

The Reuse web portal option is removed from Pega Platform 8.5 and later.

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

App developers need to use the migration tool available on the mobile channel to move their apps to the recommended new navigation designer. When users open existing mobile channel with the Reuse web portal option configured, they are prompted to run through the wizard to upgrade the mobile channel to the latest Pega Mobile Client based configuration. When this is done, app developers should rebuild the app.

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.

External data flow rules are deprecated

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.