Published Release Notes

Data flow destination is resolved at assembly time

Data flow execution always uses the design-time destination data sets or destination data flows, regardless of the input records at run time.

Example:

You create a data flow and set the destination to a specific data set. In the data flow, you use a strategy that produces some results. Regardless of these results, the execution of your data flow always uses the destination data set that you specified when you designed the data flow.    

The same applies when you set the destination to a data flow.

Problem with truncating Decision Data Store data set

The Truncate operation for the Decision Data Store data set may cause timeout exceptions. This problem is caused by the Apache Cassandra database that waits until compaction tasks finish before it can truncate the data set.

Recommendation:

Repeat the Truncate operation until it is successful.

Unable to create text analytics models when Java 2 Security is enabled

Security exceptions that prevent you from creating text analytics models are caused by the Java 2 Security feature that is enabled at the JVM level. This feature denies access to the text analytics resources that are required for text parsing functions.

Creating a text analytics model results in a failure because of a number of security-related exceptions, for example:

java.security.AccessControlException: Access denied ("java.lang.RuntimePermission""createSecurityManager")

The suggested approach for avoiding this problem is to use the text analytics models that are provided by default, for example, pySentimentModels, pyTelecomTaxonomy, and so on.

For more information, see Text Analyzer.

Extension attributes are not supported in PMML models

Models in the Predictive Model Markup Language (PMML) format version 4.3 that contain extension attributes with the x- prefix are not valid. These extension attributes are deprecated; you must use extension elements instead. In addition, if the output type of any output field in the model is set to FLOAT, change it to DOUBLE.

For more information, see PMML 4.3 - General Structure in the Data Mining Group documentation.

The Upload responses action is not supported for adaptive models with customized context

A default instance of the Adaptive Model rule contains five model identifiers (.pyIssue, .pyGroup, .pyName, .pyDirection, .pyChannel) that are used to partition adaptive models. If you add other identifiers in your Adaptive Model rule instance, you cannot upload responses to this instance with the Upload Responses wizard and the following error is displayed: The Flow Action post-processing activity pzUploadCSVFile failed: Cannot parse csv file.You can still train such adaptive models with data flows.

For more information, see Training adaptive models in bulk with data flows, Model context, and Uploading customer responses.

Upgrading Adaptive Decision Manager data mart tables might fail

Issue: Upgrade from 7.3 to 7.3.1 fails if the data contained in the pxInsName column of the PR_DATA_DM_ADMMART_PRED_FACT table is longer than 128 characters.

Reason: During the Pega Platform™ upgrade from 7.3 to 7.3.1, data in the Adaptive Decision Manager (ADM) data mart tables is migrated from the PR_DATA_DM_ADMMART_PRED_FACT table to the PR_DATA_DM_ADMMART_MDL_FACT table. In Pega 7.3.1, ADM uses only the PR_DATA_DM_ADMMART_MDL_FACT table where the pxInsName property can store values that are 128 characters long. In Pega Platform 7.3, the pxInsName property in the PR_DATA_DM_ADMMART_PRED_FACT table can store values that are 255 characters long. If the pxInsName property contains values that are longer that 128 characters, the upgrade fails.

Resolution: Issue an ALTER TABLE statement to change the pxInsName column size to 255 characters and resume the upgrade. For example:

ALTER TABLE rules.pr_data_dm_admmart_pred ALTER COLUMN pxInsName TYPE varchar(255);

For more information, see Adaptive Decision Manager data model.