Discussion
Usage of $ANY / $CLASS / $NONE in Activities
We are upgrading a 5.5 Application to 7.1.8
The 5.5 application has several activities that use $ANY in its Pages & Classes tab.
Post upgrade to Pega 7.1.8 we are getting the following error.
'Invalid expression or reference: When used with a "For Each Embedded Page" option, the step page should reference a list or group property.'
We are aware that till 7.1.4 Pega7 accepted $ANY in its Pages & Classes tab. Were there any changes post 7.1.4 that is causing this issue.
Is there any landing page or tool that can tackle this issue in 7.1.8 ?
Kindly post your suggestions.
Also $None references from 5.5 are defaulted to blank in 7.1.8
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Thanks for the response. Do we know why these restrictions were introduced ?
From different sources I understand that, using $ANY have impact in terms of maintenance and testing costs for the customer, because the engine is not able to do as much type-checking in situations where $ANY is used, therefore the customer loses some validation (save-time validation). When the engine sees a class of "$ANY" it doesn't attempt to validate that reference because it doesn't know the class of the rule, so it cannot validate whether or not it exists.
Thanks Pallavi for the response. One more point to consider while providing Sizing/estimates.
We are yet to explore...
UpgradeEstimator Portal > Launch > Upgrade Estimator > Effort Analysis Tab > Effort Type Report
Hoping this pie chart will lead us to all the affected activities in our application.
REFERENCE
https://pdn.pega.com/exchange/components/upgrade-estimator-tool
We have explored this pie chart and it will help us to identify / isolate activities that have used $ANY / $CLASS / $NONE
When we drill-down into the chart; we will find details such as "class / rulename / rulesetname / rulesetversion" of the affected activities.
We recently upgraded an application from 6.2.1 to 7.1.9 and post upgrade...
- We have no active development as such OR enhancements going forward.
- At runtime most activities (that have $ANY / $CLASS / $NONE) did not throw errors in QA / UAT.
- Most errors occured at design time only; while editing / resaving / revalidating these activities in DEV.
We did not touch the affected activities as far as they did not throw runtime errors. When we were forced to edit these activities (for whatever reason) we did the bare minimum changes that will let us ‘save’ them without any design time errors.
Bottom-line; take a reactive approach. If an activity breaks at runtime fix it else don’t bother to change anything; leave them as such in PRPC 7.X
There is no OOTB way to fix these issues and there is no generic solution for this. We need to identify manually and fix. Pega has restricted the usage of $Any/ $CLASS / $NONE.