PI Analysis: Auto-backfill should not skip analyses - ones that hasn't had an new value in a while (72+hrs)

Need more clarifications on this request. The way analyses work is that they execute based on a trigger. So if within the last 72 hours, there has not been any new triggers, there's nothing to backfill. So the statement: "Instead of AF deciding to not backfill in such cases, it should go ahead and run through the analysis for the last 72 hours regardless, or at least have an option to do so." doesn't make sense as there would be no triggers so how would we know when to execute the analyses within those 72 hours?

We have encountered this issue, not with Trigger based analyses, but with periodic scheduled analyses. For example, an analysis is scheduled for once a day, but since its a monthly KPI calculation, it only outputs once a month. The apparent behavior is that AF is utilizing the time since last output to determine the need for backfilling. What i would expect now is that if the last output was 4/1/18, then that analysis will have a backfill error anytime an auto-backfill (analysis restart) occurs after 4/3/18 . . . even if i would not expect another output until 5/1/18.

@Stephen, I think the issue here is that if the last execution time is older than the MaximumAllowedAutoBackfillingSpanInHours parameter, the backfilling of this analysis will be skipped, meaning that even if there were any newer values within the last 72 hours, they will not be evaluated. Additionally, if there are legitimately no values within the last 72 hours, and the previous value was older than that as well, then the analysis will go into error with the status: The auto-backfilling interval [interval] exceeds maximum allowed limit (72 Hours), which is a bit misleading because the analysis was never in error. I believe that one way to fix this problem is to compare the timestamp at which the PI Analysis engine was last running before being stopped/restarted. If the last execution time (as specified in PIAnalysisNotifications\Data\ActiveCalculations) is older than the stop/restart time of PI Analysis, the MaximumAllowedAutoBackfillingSpanInHours parameter should be compared to the stop/restart time instead of the last execution time. This way, if PI Analysis stopped over 72 hours ago, then we will skip the backfill. Otherwise, if PI Analysis stopped less than 72 hours ago, but the calculations didn't output anything for a time period longer than that, PI Analysis should look for triggers of those calculations from when PI Analysis was stopped, and not from the last output execution time.

Hi all, With the AF 2018 release, we have changed this approach a little bit so I think it will help with this request.  Starting with the AF 2018 release, rather than using the last output timestamp to determine whether to auto-backfill as a result of PI Analysis Service restart, we now use the last analysis execution time.  This covers the use case whereby not all executions may generate an output.  Your feedback is appreciated if this solves your use case.

This seem like it would conflict or be problematic IF this other suggestion was followed through . . . https://feedback.osisoft.com/forums/555148-pi-server/suggestions/18914053-periodic-trigger-monthly-and-yearly Is this other suggestion being declined or moved forward on?

Can you clarify, maybe with an example, why you think there would be a conflict or be problematic?

Currently the longest duration that can be set on a periodic analysis is once per day. Thus using the last execution time, any periodic analysis, regardless of output, will have a recent execution <72 hours . . . however . . . The other feedback items is about having longer duration periodic frequencies; monthly, yearly and weekly is mentioned in the comments. Under this scenario a periodic analysis could have execution times greater than 72 hours ago under normal conditions. I suppose it may be worth mentioning another edge case for triggered analyses. It would not be difficult to have a triggered analysis to be triggered by a data point that is very infrequent. We have several examples of data being received through an RDBMS interface from a MySQL table . . . this data is manually entered once a month. A triggered analysis would only execute once a month, thereby exceeding the 72 hour restriction.

Currently the auto-backfill time range is global and also user configurable. The ultimate goal of course to to ensure users don't lose data and that the system automatically fill in any missed calculations due to downtime. So in the case where an analysis' last executive time was outside the default 72 hours limit, then auto-backfill would not do anything for this particular analysis. That seems like it's desired behavior since nothing would've gotten executed during the last 72 hours anyway if the service hadn't been restarted. Maybe I'm missing something here.......

I think the use cases here are sufficiently niche/fringe and hypothetical (since the other feedback item hasn't been implemented either) . . . along with the fact that my personal experience on this particular matter is hazy since its been a little while (and my experiences pertaining to this were at least 2 versions ago) . . . thus i'm going to let it drop. The issue can be readdressed if necessary if and when it comes up. Thanks.