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.
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.
Optimized data schema upgrade
Valid from Pega Version 8.5
Several improvements have been made to optimize the speed of the data schema upgrade to help you experience minimal downtime during upgrade to Pega Platform 8.5™. The data schema upgrade process optimizations include the following improvements:
- Optimized database index creation during upgrade
- Optimized synchronization process to detect duplicate rules during the application import process
- A new upgrade setting for Pega Cloud® Services operators that reduces the time to upgrade clients that run large Pega applications, such as the CRM Suite
For more information, see Limit upgrade downtime with data schema upgrade improvements (8.5).
Default value of the threadpoolsize agent affects batch indexing
Valid from Pega Version 8.5.2
After you patch Pega Platform to version 8.5.2 or higher, the system changes the default value of the threadpoolsize agent, which controls the number of concurrent activities (threads) in the system, from 5 to 15. Batch indexing in Pega Platform™ does not require all 15 threads, so you can change the agent value to increase system performance by managing the indexing/distributed/batch/numworkers dynamic system setting.
If your deployment does not support that setting, and batch indexing does not use Queue Processors, the system uses the threadpoolsize value for batch indexing instead.
For more information, see Editing a dynamic system setting.
Upgrading to Hazelcast 4.x requires downtime during upgrades to Pega Infinity 8.6
Valid from Pega Version 8.6
Upgrade impact statement
On-premises upgrades of Pega Infinity release 8.4.2 and later to version 8.5.1 or later on Tomcat and PostgreSQL are completed with near-zero downtime. However, upgrading to Hazelcast 4.x requires that you shut down and restart your application server.
What is required to update the application to be compatible with this change?
Hazelcast 3.x is enabled by default. For near-zero downtime upgrades, you do not need to perform any action.
For instructions about upgrading to Hazelcast 4.x, see one of the following topics:
- For near-zero downtime upgrades from Pega Infinity release 8.4.2 or later on Tomcat and PostgreSQL, see "Optional: upgrading to Pega Platform version 8.6: Upgrading to Hazelcast 4.x" in Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Tomcat and PostgreSQL.
- For all other upgrades, see "Optional: upgrading to Hazelcast 4.x" in the appropriate upgrade guide.
Deprecated support for Pega Platform deployments on embedded Cassandra
Valid from Pega Version 8.6
If you use Pega Platform™ decision management capabilities, Pega Platform uses Cassandra as the underlying storage system for the Decision Data Store (DDS), which manages the Cassandra cluster and stores decision management data in a Cassandra database. Future versions of Pega Platform will no longer support deployments on embedded Cassandra. In Pega Platform version 8.6, deployments using embedded Cassandra are deprecated but still work. To ensure future compatibility, do not create any new installations using embedded Cassandra.
For information about how to configure Pega Platform to access an external database, see Defining Pega Platform access to an external Cassandra database.
Case archiving enhancements in Pega Cloud Services
To provide a more complete archiving solution to Pega Cloud clients, we have introduced several enhancements to the archival functionality for your Pega Platform database. This includes support for your data retention policy to expunge (permanently delete) archived data from Pega Cloud File Storage.
Permanently delete case data with data retention policy
In previous versions, Pega Cloud clients could archive resolved cases and associated data from the Pega database to Pega Cloud File Storage after the cases have been resolved for a specified number of days with an archival policy. Now, clients can permanently delete archived data from Pega Cloud File Storage after the cases have been resolved for a specified number of days with a data retention policy.
Faster adoption with testing mode
Clients can now enable a testing mode and specify archival policies in minutes instead of days. Now you create and resolve cases, then run archiving process immediately to test the functionality within minutes.
Easier adoptions with enhanced monitoring capabilities
With the addition of the Log-ArchivalSummary class and its associated log files, clients can monitor their archival jobs in a single view. We have also improved logging for archival jobs, offering you greater insight into the success of your archival process.
To learn more about archiving and purging your case data in your Pega Cloud environment, see Improving performance by archiving cases.
Improved indexing of StringList and StringGroup property types
Valid from Pega Version 8.6
Search and Reporting Service in Pega Platform™ 8.5 may improperly index StringList and StringGroup property types. As a result, the data model does not include the affected properties.
Upgrade impact
After upgrading to Pega Platform version 8.6, the system requires that the classes with the StringList or StringGroup type are reindexed.
What steps are required to update the application to be compatible with this change?
On the Search Landing Page, manually reindex all the classes that include properties with the StringList or StringGroup types to ensure that all your data is present in the data model. Alternatively, if finding specific instances of classes is difficult, you can reindex all classes in your application.
For more information, see Indexing class data.
LDAP Authentication Service URL resolution
The latest Pega Cloud infrastructure update includes Java JDK (JDK 89u181), which contains improvements to LDAP support. This Java JDK enhancement can prevent insecure logins by verifying that the hostname specified in the LDAP URL matches the hostname that you specified in the Trust store certificate in the JNDI Binding Parameters section of the Authentication Service rule. An LDAP Authentication Service can no longer resolve using IP addresses.
This is a one-time fix and does not affect Pega Cloud clients with security-compliant LDAP settings and certificates.
Required client workaround
For clients that previously configured LDAP in their applications running in a Pega Cloud environment using IP addresses, after Pega Cloud Services notifies you that the update is complete, you must edit your LDAP Authentication Service rule form Directory field to use the URL value of the domain name or a machine within the domain that matches the URL used by the SSL certificate in the Trust store.
For example, if your SSL certificate uses the test.abc.com machine name, enter ldaps://test.abc.com:[portNumber] inthe Authentication Service Directory field.
For more information about creating or editing an LDAP Authentication Service, see Creating a custom authentication service.