Updated default dynamic system setting for requestor pools
Valid from Pega Version 8.4
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.
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.
Failed Robotic Assignments work queue type changed to Standard
Valid from Pega Version 8.5
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.
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.
Email Wizard support discontinued
Valid from Pega Version 8.4
Pega Platform™ no longer includes the Email Wizard. This wizard helped set up an email service for sending and receiving email in Pega Platform. The wizard generated an email account, an email listener, and an email service rule.
After an upgrade to Pega Platform 8.4 and later, existing clients must create new email accounts and email channels in App Studio. When you configure a new email channel, you add your email accounts so that customers can send and receive email by using the Pega Email Bot. Configuration of an email channel automatically generates an email listener and service email rules.
Pega File Listener process changes
Valid from Pega Version 7.2.2
Beginning with Pega 7.2.2, File Listener processes files in a different way:
- File movement in directories – Previously, files were processed from the Work directory. In Pega 7.2.2, files are processed from the source location. Files move to the Work directory only if the initial processing fails and Recovery is disabled.
- New file processing – Previously, File Listener would process all files in the source location, even if the files were added during the processing. In Pega 7.2.2, files added to the source location during processing are read the next time the File Listener starts.
For more information, see File Listener data instances.
Functionality of the pyInvokeRESTConnector rule and the pxDeferenceEndpoint rule moved to core engine
Valid from Pega Version 7.2.2
The functionality of the pyInvokeRESTConnector rule and the pxDeferenceEndpoint rule has been moved into the core engine code of the Pega 7 Platform. This change provides more consistent behavior, reduces maintenance, and reduces the risk of regression issues. As a result, you can no longer customize these rules, and upgrading the Pega 7 Platform requires special considerations if you previously customized these rules.
For more information, see Upgrading with customized pyInvokeRESTConnector and pxDeferenceEndpoint rules.
Use fast processing option does not work
Valid from Pega Version 7.3.1
The Use fast processing option on Connect REST and Service REST rule forms does not work unless you obtain the HFix-43000 hotfix from Global Customer Service.
Use the following data model guidelines when using fast processing:
- The JSON property names and the clipboard property names must match.
- The JSON tree structure and the clipboard tree structure must be similar.
- The scalar arrays in JSON must be mapped to the clipboard as page lists.
- Multi-dimensional arrays must be mapped into page lists of page lists with the same embedded property names.
In addition, page groups, value groups, and Java objects are not supported by fast processing.