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.
CyberArk password vault support added for Pega database
Valid from Pega Version 8.3
With the CyberArk password vault, you can store your systems' passwords in a secure, central location and retrieve them from that location instead of directly entering credentials into the systems. This support is available only for IBM WebSphere environments.
For more information, see Pega Platform deployment guides.
Support added for multiple mashups
Valid from Pega Version 8.3
You can now include multiple mashups on a single webpage or browser, even if the mashups have different application and authentication requirements. Use mashups to embed a Pega Platform™ application as a gadget on your website. For example, you can embed Web Chatbot and Self-Service Advisor on the same website.
For more information about mashups, see Configuring the Mashup channel.
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:
- 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.
WSDL generation error prevents invocation of SOAP services
Valid from Pega Version 8.4.2
Status
A Known Issue was introduced in the 8.4.2 Pega Platform patch release, which impacts both upgrades and new installations of that version.
Description
Due to changes introduced in the SOAP functionality for the case-mismatch error in SR-D98509/INC-119725, the WSDL is being generated for SOAP services with an incorrectly-capitalized element, which prevents the service from being invoked. The element should be “name” instead of “Name”.
Workaround
Clients must perform the following workaround after they define a new SOAP connector in Pega Platform:
- To download the WSDL from Pega Platform:
- After using the SOAP Wizard (Dev Studio > Configure > Integration > Services > Service Wizard) the WSDL URL is shown at the bottom right of the Dev Studio screen.
- Click the URL to display the XML.
- Save the WSDL file to your local system.
- In the text editor of your choice, modify "Name" to "name" in every <element “name” = … > tag in the WDSL.
- Save your changes to the local file.
- To reload the WSDL into Pega Platform:
- In Dev Studio, open the Configure menu.
- Select Integration > Connectors > Create SOAP Integration.
- In the New SOAP integration wizard, select Upload WSDL from File.
- Complete the upload using the wizard prompts.
This is a design-time issue, not a run-time issue; therefore, clients only have to perform this workaround process once. Existing SOAP services should not be impacted; however, if clients modify an existing SOAP service definition by re-running the wizard, clients must reapply the workaround for Pega Platform to recognize the SOAP definition changes.
Resolution
This issue will be addressed in the Pega Platform Patch Release 8.4.3. Clients who upgrade to that version or later should not see this issue.
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.