Published Release Notes

Updated default dynamic system setting for requestor pools

Clients can now enable or disable requestor pools for processing service requests using a new dynamic system setting called EnableRequestorPools with Pega-IntegrationEngine as the owning rulest. Previously, all deployments utilized requestor pools to improve service processing response efficiency; requestor pools eliminated overhead by automatically returning a requestor to the pool after it fulfills a service request. Starting in Pega Platform 8.4, requestor pools are disabled in Client-managed cloud deployments, since these deployments use autoscaling to handle service request traffic. Enabling requestor pools in Kubernetes environments is not recommended, because they can inhibit the default autoscaling settings in the environment.

Requestor pools remain enabled by default in Pega Cloud and on-premises environments.

To help clients navigate this change, Pega has updated its best practice guidance for configuring requestor pools. For an overview, see Requestor pooling for services. For guidance on the use of requestor pools in your application, see the EnableRequestorPools entry in Dynamic system settings data instances.

Upgrade impact

Requestor pools are disabled by default in Pega Platform 8.4 in client-managed cloud deployments. Clients who deployed previous versions of Pega Platform on a Kubernetes environment and who upgrade to Pega Platform 8.4 could see that their services behave differently.

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

If clients that are deployed in a Client-managed cloud environment need to configure their services to use requestor pools and they understand how to configure requestor pools for their optimized use, these clients can re-enable requestor pools. Clients should review the best practice for configuring requestor pools before they re-enable requestor pools. To re-enable requestor pools, you modify the EnableRequestorPools setting in the Pega-IntegrationEngine Owning ruleset from “disabled” to Enabled [no value]. For details, see Editing a dynamic system setting.

Privilege required for Recent Explorer

Users with custom roles defined must add the pxUpdateRecents privilege to see work in the Recent Items Explorer. 

Use standard Developer portal

Customized versions of the Developer portal rely on legacy components and are not supported.

To avoid backwards compatibility issues, update your access group to point to the standard Developer portal prior to upgrade.

Top-level (named) pages may no longer be classless

Newly created top-level (named) pages may no longer be classless or have a blank pxObjClass property. This change can affect applications upgrading from versions prior to Pega 7 to the latest version, especially when:

• Application logic relies on a blank value in the pxObjClass property.
• An activity assumes a new top-level page is classless and explicitly sets pxObjClass in a Property-Set step.
• A data transform assumes a new top-level page is classless and explicitly sets pxObjClass using a Set action.

To avoid application failures, remove or update any logic that expects a blank pxObjClass. Where possible, use the new engine API that finds a page by both name and class:

findPageWithException(PageName, ClassName);

Activities and data transforms continue to create a top-level page when one does not exist. The class name is now derived from the Pages and Classes tab.

Existing collections are deprecated

The original implementation of the Collection form is deprecated. Legacy instances in your application remain functional; however, any new instance you create uses the redesigned Collection form. Use the Decision category in the Records Explorer to view all collections available to you.

For guidance on upgrade limitations, see the Deprecated Collection form.

Messages are rule resolved by class

As part of the Message form redesign, a class key part was introduced. While this key part is automatically handled as part of an upgrade or migration, it does change the available options you see in message SmartPrompts and how Rule-Message instances are rule resolved.

See Upgrade considerations for existing messages for more information.

Changes to archive.info in Pega 7.1.7

In Pega 7.1.7, the contents of the archive.info file have changed.

• In versions Pega 7.1.6 and earlier, the archive.info file displays the build number of the Pega installation.
• As of Pega 7.1.7, the build number no longer appears in the archive.info file.

In Pega 7.1.7, the archive.info file only displays a status message indicating whether or not the system is running, and the build number no longer appears. Instead, if the system is operational, the message “status=Running” displays in the archive.info file.

If there are any automated tests, scripts, or applications that rely on the archive.info file displaying the build number, those may fail and produce an error. It is recommended that any automation that relies on the build number displaying in the archive.info file be changed to look for the “status=Running” message.

All tabs are accessible on delegated rule forms

Delegates can now access all tabs in a delegated rule form.

You can continue to customize the development experience for delegated users, such as line managers, who may not require the full set of rule form options. For example, you can prevent users from adding new nodes on the Decision Tree form or using the expression builder on the Map Value form. All users, including delegated users, can remove these restrictions if they hold a rule-editing privilege.

For more details on this process and a list of commonly delegated rules, see How to delegate a rule.

End of support for form-based rule forms in Pega 7.1.9

Rule forms that are configured to render as forms are no longer supported in Designer Studio or end-user applications. Form-based configurations are found on custom rule types that were created in earlier versions of Pega 7 and are characterized by pop-up windows that are rendered externally from Designer Studio.

Reconfigure Pega 7 applications that use such rule forms by using standard harnesses and sections.

1. Open the class form.
2. Click the Advanced tab.
3. Select Harness from the Rule formmenu.
4. Create a new harness and new sections that implement the logic of the custom rule, using standard user interface layouts and controls.

Migrating custom rule forms to harnesses and sections offers the following benefits:

• User interfaces become HTML5 WC3 compatible and responsive to different screen sizes.
• User interfaces become cross-browser compatible, rendered consistently in Google Chrome, Mozilla Firefox, Apple Safari, and recent versions of Microsoft Internet Explorer.
• Rendering performance on modern browsers is dramatically improved.
• User interface pop-up behavior is eliminated; all windows are rendered inside Designer Studio and end-user applications.

Deprecated rule types

The following rule types have been deprecated as of the Pega 7.1.8 release:

• Form
• Hierarchy
• Service COM
• Service BPEL
• Connect BPEL
• Parse Transform
• Parse Transform Collection
• Parse Infer

For more information, including suggested alternate rule types, see the help topic Deprecated features.