The rollup takes the timestamp from the input attributes. If these are not PI Point, these likely cause the date you are seeing.
Can you show a bit more about your data & configuration to help you pinpoint the problem?
1 of 1 people found this helpful
This would make it seem like the person configuring this actively changed the configuration from using a PI point data reference to using no data reference. This behavior usually requires first creating the rollup and then changing the configuration later. We added checks in 2.7.0 to discourage users from doing this. It is not recommended. Since the attribute is printing out the timestamp of the data reference, it will continue to show no timestamp as long as it is a "None" data reference. The recommendation is to write the data to a PI point.
Sorry for the late response. All the attributes configured in the rollup calculation are Table Lookup DR (3rd part data source) not the PI Point data reference. Also, DR have not changed from the beginning of the configuration.
Here is the illustration of the hierarchy.
-- Group 2 -Configured RollupSum at level on attribute "Attr1" at periodic interval of 10 minutes or less and expecting that it would honor the timestamp of "Attr1".The result is not being written to tag
Attr1Sum - Group3 Sum
----- Group 3 -- Configured RollupSum at this level on attribute "Attr1" at periodic interval of 5 minutes and expecting that it would honor the timestamp of "Attr1". The result is not being written to tag
Attr1Sum - The result is not being written to tag -- Sum of all Elements under Group1
+ Element 1
Attr1 - TableDR - Show corrects time stamp from 3rd party data source (Oracle database).
+ Element 2
+ Element 3
3rd part data source is single source of truth and don't want to have source data in multiple places. hence, all calculation are being configured as dynamic at this moment in AF to make them available in PI Coresight
Right, it's fine that you're aggregating non PI Point DRs in your rollup, but the result is always going to read off the timestamp of the DR which it is writing to. In this case, that is no DR, which will always result in a client timestamp of January 1, 1970. So while the hierarchy looks correct, and I have no doubt that Oracle has the correct timestamp and that the Table Lookup DR is correctly configured to give the correct value/timestamp combination, if the rollup (Attr1Sum) does not output to a tag, you will only be able to get the right value, at best. Even then, there's no troubleshooting mechanism to figure out if the value is correct because there's no timestamp to correspond it to.
It sounds like you are writing to all (or many) non PI Point DRs with analyses. I would strongly caution against that. This is not a recommended configuration and could result in performance issues as you attempt to scale up. Also, I would caution against thinking that this is "dynamic". It's much closer to "static" as it has no time context to it.