Change tracking tab removed from declare expressions
Valid from Pega Version 8.3
To simplify the configuration of a declare expression, the Change tracking tab has been removed from the declare expression rule form. To use the Change tracking tab, on the declare expression rule form, click Actions > Use legacy expression.
For more information, see Supported and unsupported configurations in simplified declare expressions.
Upgrade impact
The declare expression rules have been moved from the pr4_rule table to the new pr4_rule_declare_expression table.
The upgrade can fail if you customize the pr4_rule table, such as increasing the length of an existing column.
After a successful upgrade, the declare expression rule form is simplified and lightweight pages support declare expressions.
What steps are required to update the application to be compatible with this change?
Read-only data pages by default are lightweight. You could also enable lightweight pages for:
- Editable data pages by selecting the Enable option in the editable data page rule form.
- For all pages in a REST service by using the Lightweight clipboard mode in the Service REST form in the Rest API service.
Only simplified declare expressions are supported in lightweight pages. In simplified declare expressions, context-bound rules are not supported. However, a page context could be specified on the New or Save As form of declare expressions. For more information, see Declare Expression rules - Completing the New or Save As form.
Redirectguests mashup configuration has been removed
Valid from Pega Version 8.3
The authentication/redirectguests server configuration and data-pega-redirectguests attribute have been removed and are no longer required when you configure a mashup. This prevents you from needing to maintain multiple nodes to support some use cases that require the configuration value to be true and other uses cases that require the configuration value to be false.
For more information, see Configuring the Mashup channel.
BIX ruleset is now included with Pega Platform
Valid from Pega Version 8.3
The Pega Business Intelligence Exchange™ (BIX) ruleset is now included with Pega Platform™, which eliminates the need for additional provisioning for Pega Cloud customers and for a separate BIX installation for on-premises customers. To add BIX to your application, add the Pega-BIX:<version> ruleset to your application rulesets.
For more information, see Data extraction.
Upgrade impact
After a successful upgrade, the BIX ruleset is available within Pega Platform. You should synchronize the BIX ruleset and Pega rules to avoid extraction errors.
What steps are required to update the application to be compatible with this change?
After the upgrade is complete, change the ruleset version for Pega Platform and BIX to use the same, latest version.
Improved management of batch indexing
Valid from Pega Version 8.3
You can now cancel and check the status of a batch index process directly from the Search landing page in Dev Studio. The landing page now refreshes automatically every 10 seconds so that you can easily see the most recent status of the batch index process. Additionally, the reindex operation is now 20% faster than in previous versions. These features provide greater visibility into batch indexing and improve your ability to fix issues with a batch indexing process.
For more information about batch indexing, see Rebuilding search indexes from the user interface.
.
Improved performance for work ID generation
Valid from Pega Version 8.3
Work IDs are now generated in batches and managed with dynamic system settings. Batch-based ID generation improves performance and scalability, which reduces the time that it takes to migrate data to a Pega Platform™ application.
For more information, see Default dynamic system settings data instances.
Upgrade impact
In a multi-node environment, the new ID generation method can assign IDs that are not as sequential as in the previous method.
For example, in a 2-node cluster, the IDs could come in from each node in batches of 1000, resulting in successive Work objects having IDs that differ by 1000 (such as 1, 1001, 2,1002, 3, 1003). As more Work objects are created the gaps can get filled. However, there might still be gaps left in the generated IDs. For example, if a node crashes or shuts down, some IDs would be missing, or if a node has given out 600 IDs from a batch of 1000 IDs, then 400 IDs would remain unused. In most situations, this should not be an issue.
What steps are required to update the application to be compatible with this change?
If you must have nearly sequential IDs or cannot accept gaps in IDs (and do not need the performance improvement), then you can change the dynamic system setting to disable the new ID generation method.
The dynamic system setting for this feature is idGenerator/defaultBatchSize. The feature is enabled by default with a defaultBatchSize of 1000. To disable the feature, set the value to 1.
Improved control of case locking and retry mechanisms
Valid from Pega Version 8.3
The Delay factor, Initial delay in minutes, and Max retry attempts fields have been added to queue processors, and the Timeout to acquire lock field has been added to the Queue-For-Processing method. Using these fields, you can quickly configure background processes that require you to lock cases or retry case processing.
For more information, see Creating a Queue Processor rule.
Upgrade impact
After a successful upgrade, the new fields contain their default values.
What steps are required to update the application to be compatible with this change?
To customize the functionality of this feature (and the new fields), open the Queue-For-Processing definition and modify the values for the new properties or fields.
Automatic management of run-time context for background processing
Valid from Pega Version 8.3
Management of system run-time context is now automatic. You no longer need to manually modify the AsyncProcessor requestor type context to make a queue processor or job scheduler work after importing or upgrading an application. Additionally, you do not need to manually modify the AsyncProcessor requestor type context to make new queue processors and job schedulers work.
For more information, see System general landing page and Automating the runtime context management of background processes.
Upgrade impact
After upgrade, you manage the runtime context of your background processing in System Runtime Context instead of in the deprecated AsyncProcessor requestor type.
What steps are required to update the application to be compatible with this change?
Select the Include in background processing option in the Advanced section of the application rule form for all applications that use background processing (such as Job Schedulers and Queue Processing). When this option is enabled, the system automatically includes the rulesets (for the application and its components) in System Runtime Context used for resolving and running Queue Processors and Job Schedulers. Also, when the option is enabled, the application is placed on the System Runtime Context list during application rule saves (such as during application import and migration).
Define a default reporting database
Valid from Pega Version 8.3
You can now easily define a reporting database for all classes that are assigned to a primary database. You can also assign this reporting database as the default reporting database. This provides support for reporting against Amazon Aurora read replicas. AWS Aurora increases the performance and stability of your database management system.
For more information about reporting, see Report Definition data access tab.