arosenthal
My feedback
-
7 votesarosenthal
supported this idea
·
-
18 votesarosenthal
supported this idea
·
An error occurred while saving the comment An error occurred while saving the comment arosenthal
commented
Some sort of error handling is definitely needed for this scenario. Currently it's hard to separate rollup analysis errors when attributes can't be found from legitimate rollup analysis errors. At a minimum, there should be a way to ignore/hide this error, but it would be better if rollup analysis was able to use a default value or just gracefully skip over attributes that don't exist.
arosenthal
shared this idea
·
-
35 votes
Can you clarify if your use case has 1 output PI Point or multiple PI Point(s)?
Is there any reason why you are not using RDBMS interface to bring your table data into the PI System? That would remove a lot of complexity and greatly improve performance.
arosenthal
shared this idea
·
In response to Rick Davin, "The use-case is having a Rollup Analysis..."
Exactly. This can also cause problems when the AF hierarchy changes over time. If at one time a parent had child elements, then the rollup analysis on the parent element could have value X. Then, if the AF hierarchy is changed so that the parent element no longer has child elements, the rollup analysis will fail, and the attribute value on that parent element will be stuck at value X forever. If the attribute values on the parent elements are used as inputs to rollups further up the hierarchy, this can really corrupt your data.
I have this exact situation currently as my AF hierarchy changes every week, and I have to run custom scripts to detect rollup analysis in a failed state but with an output that has "good" quality. I have to get a list of the PI tags for those outputs and reset their values using piconfig.