Published Release Notes

Improved search indexing performance

Search indexing now uses a queue processor to improve indexing performance. Indexing can automatically restart if the database goes down temporarily. This saves time and manual action. As a result of using the queue processor for indexing, the following changes have been made to the Search Landing page.

• You cannot cancel indexing from the Search landing page. Cancel indexing by stopping the queue processor from the Data flow landing page.
• The progress message is not shown. View progress on the Queue Processor landing page.
• Queue processor information has been added.

For more information, see Stopping or pausing search reindexing.

More visibility of your production level

You can now see the production level of your environment in a new gadget that is available in all Pega Platform™ workspaces. To ensure that you immediately recognize your current environment, you can give it a unique name that is displayed when you click the gadget. In addition to specifying your production level and environment name on the System form in Dev Studio, you can now specify those values on the System & nodes page in Admin Studio.

For more information on Admin Studio, see Modifying your environment name and production level.

For more information on Dev Studio, see Specifying the production level.

Analyze decision components with simulation tests

Gain a better understanding of how strategy components influence decision outcomes by using decision funnel explanations. By running simulation tests with the new Decision funnel explanation purpose, you can now break down the results of a decision funnel into granular analyses to assess how certain components and expressions influence the overall outcome.

For more information, see Interpret the decision funnel with simulation tests.

Rule revalidation after updating properties without restarting nodes

When you update certain property attributes, such as a property's maximum length, rule types that reference the property might not reflect the change. You do not always have to restart nodes to revalidate the referencing rules when they cannot be resaved, for example, when they are in a locked ruleset. For Pega Platform™ 8.1 and later, for non-stream rules, such as activities, data transforms, and so on, use the reassemble API in Admin Studio or truncate the assembled classes table.

For stream rules, such as sections, harnesses, paragraphs, and so on, reassemble the rules and restart the nodes. For more information, see More about properties.

For previous versions of Pega Platform, use the System Management Application (SMA) to revalidate stream and non-stream rules.

Support for machine learning as a service models

In Pega Platform™, you can now run advanced machine learning and artificial intelligence models that you develop in third-party tools. By configuring a connection with an external machine learning as a service provider, such as Google AI Platform, you can use the predictive power of your custom models to improve the predictions in your customer strategies.

For more information, see Connecting to a Machine Learning as a Service model and Configuring a machine learning service connection.

Improved management of batch indexing

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.

.

Changes in JSON results when checking the health of your system

Beginning with Pega Platform™ 8.2, the JSON results that are returned when you ping a Pega Platform instance have changed. JSON results now include node type and health information, including test name, status, state, and node ID. The following samples show JSON results from versions before 8.2 and as of 8.2.

JSON results for pre-Pega Platform 8.2:

{ "duration":"3954.448601", "count":"0" }

JSON results for Pega Platform 8.2 and later:

{"node_type":["WebUser"],"health":[{"last_reported_time":"2019-02-14T16:10:49.589Z","test_name":"Sample-Stream-Check","status":"success"}],"state":"healthy","node_id":"10.10.10_samplenode"}.

Stream-based alternative for interaction history

Accelerate the processing of high-volume interaction history data by incorporating a stream-based interaction history into your application. A stream-based interaction history processes large volumes of data more quickly than a traditional relational database interaction history so that you can react to your customers' needs in real time.

For more information, see Process high-volume interactions more efficiently and Aggregates-only mode for a stream-based interaction history.

Aggregates-only mode for a stream-based interaction history

Activate the aggregates-only mode to efficiently transition your application from a relational database interaction history to a stream-based interaction history. By transitioning from a traditional relational database interaction history to a stream-based interaction history, you enable your application to process large volumes of data more quickly so that you can react to your customers' needs in real time.

For more information, see Transitioning to a stream-based interaction history.

Improved performance for work ID generation

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.