Skip to main content

Published Release Notes

Find release notes for the selected Pega Version and Capability

Browse resolved issues for Platform releases.

This documentation is for non-current versions of Pega Platform. For current release notes, go here.

Unit testing support for more rule types

Valid from Pega Version 8.3

You can now create unit tests for the following additional rule types. You can also create assertions to validate activity status. The expanded rule types for unit testing enable developers to more thoroughly perform regression testing of their application, thereby improving application quality.

  • Collection
  • Declare expression
  • Map value
  • Report definition

For more information about unit testing rules, see Pega unit test cases.

Upgrade impact

With the four new rule types, unit test execution and unit test compliance metrics will change. Reports on automated unit testing of the customer application decrease due to the increased pool of supported rules.

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

After a successful upgrade, create Pega unit test cases for the newly supported rules to see updated and accurate unit test metrics.

Use Page-Change-Class method to change a Page class

Valid from Pega Version 8.3

With the release of Pega Platform™ 8.3, using the Property-Set method to change the Page class shows a guardrail warning. Use the Page-Change-Class method to change the Page class instead.

For more information about the Page-Change-Class method, see Changing the class of a page and Page-Change-Class method.

Changes to URL format for Pega Web Mashup

Valid from Pega Version 8.3

The format of Pega Web Mashup URLs now supports multiple mashups on a single web page. The new URL format prevents a mashup from sharing cookies with another mashup.

If you want to include multiple mashups on a single web page and one of the mashups was created before 8.3, you must regenerate the mashup to reflect the new URL format.

For more information, see <link to help topic>.

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:

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.

Set a time zone for the DateTime control

Valid from Pega Version 8.3

The DateTime control now supports the selection of a specific time zone. Apart from the default local time zone, you can choose a Java-supported time zone or enter a property. For example, you can make it easier for a manager working in New York to schedule a task for a worker in London by configuring a calendar picker on user forms to show a date and time for Europe/London.

Beginning with this release, the calendar picker defaults to the current time in the time zone that is defined in the operator record. Previously, it defaulted to the local time zone of the system.

For more information, see Specifying a time zone for a DateTime control.

Upgrade impact

After a successful upgrade, the DateTime gadget displays the time in the current operator's locale, which is defined on the operator rule form or in the browser.  

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

If you need to display the system time from which the user has logged in, and if this is not the same as the time in the user's locale (based on the browser setting), set the Locale field in the operator ID to be blank so that the browser-based setting and the displayed time are the same as the system time.

Test coverage support for more rule types

Valid from Pega Version 8.3

Test coverage has been expanded to include the following rule types. Test coverage support for these rule types enables developers to more accurately measure the effectiveness of their tests.

  • Collection
  • Declare trigger
  • Map value
  • Navigation 
  • Report definition
  • Scorecard

For more information about test coverage, see Test coverage.

Upgrade impact

The new rule types may impact the test coverage metrics for your applications. Due to the increased number of supported rules, the reported test coverage percentage will decrease.

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

Run your coverage reports after upgrading to see the latest metrics.

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).

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us