INC-201335 · Issue 690733
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-196389 · Issue 690787
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.6.3
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-201335 · Issue 690734
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.6.3
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
SR-D66223 · Issue 529994
Update Handler will not run during migration
Resolved in Pega Version 8.3.2
Rolling restart of DataFlow, ADM ,VBD, and Util Tiers failed with a PENDING_JOINING error after an in-place upgrade. This was traced to the logic for the update timing: when nodes start after an upgrade from 7.x to 8.x they will migrate data flow runs. Migration happens on only one node, and while it's in progress the other nodes will wait until migration finishes before they come up. At this point the state of the data flow services will be 'PENDING JOINING'. The issue is that while migrating runs, the Data Flow Update Handler was triggered to validate whether there were nodes available on the service the run belongs to. This call can cause the corresponding data flow service to be initialized, but the call will be blocked since all services wait for the migration to end. This resulted in a deadlock which prevented all nodes from coming up successfully. To resolve this, the process has been updated to skip the update handler during migration to avoid triggering the initialization of client services that are waiting on the migration lock.
SR-D68707 · Issue 529869
Update Handler will not run during migration
Resolved in Pega Version 8.3.2
Rolling restart of DataFlow, ADM ,VBD, and Util Tiers failed with a PENDING_JOINING error after an in-place upgrade. This was traced to the logic for the update timing: when nodes start after an upgrade from 7.x to 8.x they will migrate data flow runs. Migration happens on only one node, and while it's in progress the other nodes will wait until migration finishes before they come up. At this point the state of the data flow services will be 'PENDING JOINING'. The issue is that while migrating runs, the Data Flow Update Handler was triggered to validate whether there were nodes available on the service the run belongs to. This call can cause the corresponding data flow service to be initialized, but the call will be blocked since all services wait for the migration to end. This resulted in a deadlock which prevented all nodes from coming up successfully. To resolve this, the process has been updated to skip the update handler during migration to avoid triggering the initialization of client services that are waiting on the migration lock.
SR-B67003 · Issue 329137
Enhancement added to validate mandatory fields in custom proposition definition forms
Resolved in Pega Version 7.4
Enhancements have been added in order to support extended customization of a proposition definition form. Previously, the custom form containing the custom fields was rendered in the context of a requestor-level, editable data page for creating a new proposition. The custom form section itself did not belong to the same class as the data page but was only rendered in the context of the data page at run-time. Therefore, validations defined on the custom form were not triggered due to the mismatch in the context of execution. The system has now been updated with an extension activity which will have the required-field validation pre-loaded. The same activity can then be extended to include additional validations whenever needed. The approach has some limitations as below. Process: On the custom form for the proposition group, the appropriate fields will need to be marked as required-always from the 'Required' dropdown field configuration form. After this, with the local fix branch included, new propositions should be validated for missing required fields. Limitations: The validation will work only on the manual creation of a new proposition. Conversely, the validation will NOT work if the propositions were uploaded using the Import/Export feature on the Decision Data form. The validation error messages for the custom fields will appear on the top of the page unlike that for the proposition name property. However, the message will list all properties that are marked as required but haven't been filled-in on the form.