8.2 Data Page issues
After upgrading to 8.2.1 from 7.1.9, we began seeing a number of issues for DPs and their references.
Issue #1 - providing the data page parameter name is now required even if the DP only has a single param
The data pages in question have a single parameter, referenced in other rules without providing the parameter name, e.g. D_MyPage["somevalue"] rather than D_MyPage[MyParam: "somevalue"]. If there is only one parameter to a data then why require a named parameter in references? Is there any setting or way to turn this off? We could have 100s if not 1000s of rules that will require refactoring and no easy way to search them all without a full bulk revalidate and save.
Issue #2: Data pages sourced from report definitions do not load
Data pages with a source of report definition are all failing to load, but without providing much in terms of exception/stacktrace information. The underlying reports run, but when unit testing the DPs, no results are returned, although the tracer shows (up to the last step) that the results were fetched.. just not apparently transferred to the DP. At runtime however, errors are showing in the tracer, very generic error message
Available
US
I wrote a test activity that attempted to iterate over the pxresults of the page. Tracer shows the report running, transferring its contents to the data page, but the activity just exits (without error) as soon as it is referenced... activity steps after this are not executed nor show in tracer.
Pegasystems Inc.
US
Benjamin,
For your Issue #1, let me provide some clarity here. The reason we made this change is because adding an optional parameter to any rule in Pega is considered a non-breaking change. Since the parameter is optional you don't have to modify existing callers, they will just pass in an empty value (which is ok for optional parameters). Therefore this is a safe change to make.
However what we realized was that data pages were the exception to this rule because of the special syntax you were allowed to use if the data page had a single parameter. If a data page had only a single parameter then it was not safe to add even an optional parameter to it. This is because users could be calling it by only specifying a value and not specifying the parameter name to map that value to. Which only works if the data page continues to have exactly one parameter. If a second parameter is added, even an optional one, all callers using that syntax begin throwing runtime exceptions.
This is why we made this change. We want to help everyone build in a way that is easy to maintain and upgrade as the implementation changes. Data pages that have a single parameter now may not tomorrow.
Benjamin,
For your Issue #1, let me provide some clarity here. The reason we made this change is because adding an optional parameter to any rule in Pega is considered a non-breaking change. Since the parameter is optional you don't have to modify existing callers, they will just pass in an empty value (which is ok for optional parameters). Therefore this is a safe change to make.
However what we realized was that data pages were the exception to this rule because of the special syntax you were allowed to use if the data page had a single parameter. If a data page had only a single parameter then it was not safe to add even an optional parameter to it. This is because users could be calling it by only specifying a value and not specifying the parameter name to map that value to. Which only works if the data page continues to have exactly one parameter. If a second parameter is added, even an optional one, all callers using that syntax begin throwing runtime exceptions.
This is why we made this change. We want to help everyone build in a way that is easy to maintain and upgrade as the implementation changes. Data pages that have a single parameter now may not tomorrow.
I would like to note that since your application is working fine now you don't have to immediately refactor everything. The single parameter syntax is still supported and will continue to be supported for backwards compatibility reasons. The only two reasons you would have to change all the places using that are:
- You updated a rule using the single parameter syntax. Validation errors will prevent you from saving until you use the <name>:<value> syntax for all data page references in that rule.
- You added an optional parameter to a data page that has only a single parameter. Then you will need to go locate every caller of that data page using the single parameter syntax and switch it.
Sorry for the inconvenience but hopefully this explains the reasoning for this change.
-Mike
Available
US
Thanks for the response, that is useful context - it is good to know that the rules will continue to work during runtime, but will need to be refactored later when making any changes. We noticed a similar restriction on the @java() used in expressions.