$ANY for page reference of runtime service input dose not work in Pega 7.1.8/7.1.9 although it worked in 6.3sp1 (Err :- Invalid expression or reference: When used with a "For Each Embedded Page" option, the Step page should reference a list or group prop)
Hi All,
In Activity, we are defining some properties under pages and classes tab as "$ANY" since we are not sure what the classes will be at runtime for the input data(input is a JSON). These properties are not defined in PRPC. In 6.3sp1, the below configuration worked fine and we were able to save & run the activity.
63sp1 -- pages &classes tab :-
DisputeManagerServicePage -- PP-FW-CMFW-Svc-Case
DisputeManagerServicePage.dispute_represent -- $ANY
DisputeManagerServicePage.dispute_represent.case_seq() -- $ANY
63sp1 -- activity usage :-
However in 719/718, we are getting the below error trying to save the same activity :-
Hi All,
In Activity, we are defining some properties under pages and classes tab as "$ANY" since we are not sure what the classes will be at runtime for the input data(input is a JSON). These properties are not defined in PRPC. In 6.3sp1, the below configuration worked fine and we were able to save & run the activity.
63sp1 -- pages &classes tab :-
DisputeManagerServicePage -- PP-FW-CMFW-Svc-Case
DisputeManagerServicePage.dispute_represent -- $ANY
DisputeManagerServicePage.dispute_represent.case_seq() -- $ANY
63sp1 -- activity usage :-
However in 719/718, we are getting the below error trying to save the same activity :-
activity error :-
Question :-
Isnt this a backward compatibility bug ? If so, is there a work around ? I have tried this in my personal edition and this error does come up there as well. Tried with $none,$class;but to no luck.
How do I define place holder page lists that are not defined in the system in 71 ? (I was thinking $any would work, but it doesn't). While using PRPC service, in order to take runtime data coming from an external source to be mapped to PRPC, we are using this kind of reference so that we do not define the properties before hand but use it at runtime.
Accepted Solution
Updated: 12 Nov 2015 11:22 EST
Pegasystems Inc.
US
Nishan,
If we added additional validation, it's probably because there is an edge case out there where the code without it fails. We try our best not to require unnecessary work when you upgrade, but particularly for a big jump like 6.x to 7.x, that sort of thing will happen. Hopefully the new features and additional protection against problems that you may not even be aware of will convince the business stakeholders to approve the effort. I am not aware of there being any sort of way to only use the validation on rules you make brand new after an upgrade. I'm pretty sure any time you hit save, it runs through the validation code. I would be cautious about going down that path since there is no way to know the rule you are saving will work correctly after going through the latest save code, short of validating everything in it.
Best,
Mike
PayPal
IN
Update :
As a workaround, we have created the properties (pagelists in this case) as $any and configured it. But the question still remains as to if this is a backward compatibility bug ?
Pegasystems Inc.
US
Nishan,
I'm not familiar enough with this specific area of code to give a definitive answer, but I can say that version to version, we do occasionally tighten validation on fields as a result of issues found. The error message you are getting seems pretty deliberate so I would suspect that's what has happened in this case.
Thanks,
mike
PayPal
IN
Hello Mike,
Yes, what you are saying is absolutely correct ! However, the challenge now is that a lot of work needs to be done to circumvent this error in multiple activities (by means of creating new properties etc..). Ideally, shouldn't this validation come up only for new activities ? Isn't there a way to introduce these new validations only on 71-created activities just to support old code base ?
To justify to the business stakeholders that upgrading to Pega7 requires additional development work for already developed & implemented code is a tough nut to crack and hence the query !
Thanks,
Nishan
Accepted Solution
Updated: 12 Nov 2015 11:22 EST
Pegasystems Inc.
US
Nishan,
If we added additional validation, it's probably because there is an edge case out there where the code without it fails. We try our best not to require unnecessary work when you upgrade, but particularly for a big jump like 6.x to 7.x, that sort of thing will happen. Hopefully the new features and additional protection against problems that you may not even be aware of will convince the business stakeholders to approve the effort. I am not aware of there being any sort of way to only use the validation on rules you make brand new after an upgrade. I'm pretty sure any time you hit save, it runs through the validation code. I would be cautious about going down that path since there is no way to know the rule you are saving will work correctly after going through the latest save code, short of validating everything in it.
Best,
Mike