SR-D26976 · Issue 507215
Filter added to ensure correct context for proposition strategy rules
Resolved in Pega Version 8.1.7
Given two applications (ex App1 and App2) hosted on the same domain where App2 was built on App1, trying to create a strategy rule in App1 and do a test run strategy using the propositional data component which internally uses App2 propositions generated the error: Failed to find a 'RULE-DECISION-DECISIONPARAMETERS' with the name 'GROUP_2'. There were 1 rules with this name in the rulebase, but none matched this request." Investigation showed the strategy was using the PropositionNoCacheUtils and PropositionTools java classes to load the propositions during run time. In these classes, the group classes were browsed from the db irrespective of the application context, causing the strategy run to fail as it was not able to access the decision data rules in other applications which shared the same SR class as the current application. To resolve this, a filter has been added to the PropositionNoCacheUtils and PropositionTools java classes to filter out the groups that are not in the current application context.
SR-D31103 · Issue 502980
VBD insert process updated for better retry handling
Resolved in Pega Version 8.1.7
When restarting Data Flow and VBD nodes, the VBD client can encounter some exceptions indicating components in the stack are temporarily unavailable. In most cases the VBD client retries, but there are some cases where it did not and data flow failures occurred. To resolve this, the code has been updated to remove logging of the VBD cluster status during a retry, and the retry duration has been made configurable.
SR-D37163 · Issue 505479
Corrected Decision Data import filter behavior
Resolved in Pega Version 8.1.7
After upgrade, if a Decision data import referred another component to filter out the import, it did not work. This has been corrected.
SR-D38492 · Issue 505491
Batching now enabled when using IH Summary shape in substrategies
Resolved in Pega Version 8.1.7
Batching was not being enabled when using IH Summary shape in substrategies. This was traced to the IH_SUMMARY_CACHE field not automatically being passed to sub-strategies, and has been corrected.
SR-D39956 · Issue 511639
Corrected method IF use with shortcut function
Resolved in Pega Version 8.1.7
After upgrade, method IF was not working as expected when used in an expression like "@if(.totalorders_120days>0,(.remakeorders_120days/.totalorders_120days)<0.3,false)". This was caused by a missed use case for the combination of an exception-generating function in combination with a shortcut function (i.e. ternary, and, or), and has been resolved.
SR-D47713 · Issue 511972
Corrected issue with strategy framework testing
Resolved in Pega Version 8.1.7
Issues were seen in creating a dataflow to test the strategy framework shipped with the Pega Marketing product. It was not possible to use a data transform to test this strategy because it is in the shipped PegaMKTEngine ruleset. Investigation showed the value of appliedToClass was retrieved from "pyRunOnDataFlowClassName" instead of from the running strategy, and this has been resolved.
INC-203994 · Issue 698853
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.
INC-183706 · Issue 685830
Added null check for DynamicAppenders
Resolved in Pega Version 8.7.1
Null pointer exceptions were seen for Pulse. This has been resolved by adding a null check in the DSS save/update process.
INC-185117 · Issue 680899
Check added to disable offset support for older versions of Oracle
Resolved in Pega Version 8.7.1
An ORA-00933 error was generated after upgrading from Pega 7.1 to Pega 8.5. This was traced to a conflict between Oracle 11g and the Pega 8.5 platform related to an OFFSET statement being added to a query for a version of Oracle that doesn't support it. The preferred solution is to upgrade Oracle to address this, but in order to support backwards compatibility a check has been added which will disable offset support in Oracle if productversion <=11.
INC-202677 · Issue 698989
Handling added for missing expose.accessGroup property
Resolved in Pega Version 8.7.1
After exposing an existing page group and page list properties along with single value properties using a declare index, running the Column Populator tool prpcServiceUtils to populate the historical data resulted in the single value properties being updated in the exposed column properly, but the page group and page list properties were not updated in the declare index table. On new case creation the declare index tables were updated. This was traced to the default expose.accessGroup not being set for the user, and has been resolved by adding a check and handling that will add the missing property in prpcserviceutils.properties defining the access group for the Rule-Declare-Index of the classes being exposed if it is not present.