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.
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.
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.
Posted: 5 years ago
Posted: 4 Nov 2016 9:25 EDT
Vigneshwaran Aravindhan (VigneshAravind)
Senior Technology Architect
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