Detailed Scheduler Execution Steps
The following are the detailed execution steps performed by the Scheduler engine during the execution of the configured analysis in Sigmafine Scheduler configuration table.
Step 1: Prior to every run, the Scheduler checks if the system is within the DST/ST transition. This feature avoids very specific situations where there is an action along the DST/ST or reverse transition. A case creation within the transition can cause unpredictable effects (e.g. overlapping cases) since the AF system is not capable of intercepting cases across different time zones. The DST/ST transition checks:
The actual running time (and its time-zone)
The previous hour time (and its time-zone)
The next hour time (and its time-zone)
This check controls whether the three times gathered are in “DaylightSavingTime” and the local time zone of all the three times have the same hour offset. If this condition is met, then the system is not in the daylight savings transition and the execution can continue. In the log file, you can find the something like the following messages (check the highlighted part):
[ISINDST] ACTL TIME: \<DateTime> DAYLIGHTSAVINGS: True/False DIFF: 2 Hours
[ISINDST] PREV TIME: \<DateTime> DAYLIGHTSAVINGS: True/False DIFF: 2 Hours
[ISINDST] NEXT TIME: \<DateTime> DAYLIGHTSAVINGS: True/False DIFF: 2 Hours
Step 2: The first step of the actual execution process checks for the configured instance of the execution (for further information please see the 'INSTANCE' column of the SF_Scheduler table). If you have configured the analysis with an empty name or with the same name of the current Scheduler, the Scheduler runs the target analysis. In the log file a message, similar to the following, appears:
EXEC] Check for instance execution: \<instance name\>Step 3: The scheduler checks for the enable flag of the current analysis. Specifically, the scheduler checks for SF_Scheduler table 'ENABLE' column. In the log you should find a message similar to:
[ISTORUN]\>\>\> Checking for ENABLE FLAG in progress....Step 4: The Scheduler checks for the last execution time of the analysis. It checks the actual execution time against the last execution time (stored in the LASTRUN file/table). If the actual execution time minus the last execution time (converted in seconds) exceeds the number of seconds configured in the 'PERIOD' column inside the SF_Scheduler table, then execution continues; otherwise execution is skipped (highlighted row). In the log file, you should see the following messages:
[ISTORUN]\>\>\> First loop check for last execution..."[ISTORUN]\>\>\> Check for last execution. [UTC] Last Run = \<ExecTime\>-\<CurrTime\> [Period=XXX | Diff(in seconds)=NNN][ISTORUN]\>\>\> No minimun time elapsed (Diff \< Period). Exiting..."Step 5: The Scheduler checks if the execution is within the validity time. Specifically, if the current execution time is inside the times specified in the 'VALIDITY' column of the SF_Scheduler table. If the current execution time is outside, then the execution is skipped (highlighted row). In the message log file, you will see the following messages:
[ISTORUN]\>\>\> Check for validity period [LOCALE] = \<VALIDITY COLUMN\> - [ST=\<Start\> - ET=\<End\>] - \<Curr.Time\>[ISTORUN]\>\>\> No valid times for scheduling. Exiting...Step 6: As an additional step prior creating a new case, the Scheduler checks if you configured the analysis for the recalculation (see the 'RERUN' and 'RERUNNUM' columns in the SF_Scheduler table settings). If the 'RE-RUN' flag is activated, Scheduler checks for how many cases have to be re-run for each execution loop. So, in the instance where the 'RE-RUN' Number has been set to 5, Scheduler will re-run (performing all the steps from collect-element up to the SQL publish, if configured) for the last 5 cases starting from the oldest to the newest (the newest is the last case every time). Please keep in mind that this option works only when the 'CHECK-IN' flag has been enabled. In the message log file, you should find some messages similar to the following:
[ISTORERUN]\>\>\> Re-Run last case flag activated!!!In case of configuration error (check-in flag disabled)
[ISTORERUN]\>\>\> ERROR/FAILURE while getting last AF case! Exiting...[ISTORERUN]\>\>\> Returning \<CASE NULL: DO NOT RE-RUN\>!In case of good configuration (check-in flag enabled)
[ISTORERUN]\>\>\> Last case is: [LOCALE] StartTime=\<STARTTIME\> EndTime=\<ENDTIME\>Step 7: The Scheduler performs a tentative creation of the next case to be executed, following the configuration specified in the SF_Scheduler table and the Time-Rule in the analysis configuration. According to the different configuration, Scheduler sets the START and the END time of the upcoming case (for further information please review "AF Time Rule" settings in the OSISoft documentation) and SF_Scheduler configuration parameter section in this manual. At the end of this evaluation process, Scheduler checks the tentative END-TIME of the CASE by checking if the value is less or equal to the current execution time (the check is done in UTC), otherwise the execution is skipped. In the log file, you should see something similar to the following:
[ISTORUN]\>\>\> Check for Case Times [LOCALE] StartTime=\<START\> / EndTime=\<END\> *** NOW = \<CURR.TIME\>[ISTORUN]\>\>\> Check for Case Times [UTC ] StartTime=\<START\> / EndTime=\<END\> *** NOW = \<CURR.TIME\>[`ISTORUN]>>> Case EndTime in the future!"`
Step 8: The Scheduler checks for the DEPENDENT analyses of the current analysis under execution. If there are other analyses inside the 'DEPENDENCY' columns , Scheduler loops for all the configured analyses in the list (separated by semicolons) and for each analysis it gets from the LASTRUN file/table last execution time. If for all dependencies the ENDTIME of the target case is less or equal, the execution can be triggered, otherwise it is skipped. In the log file, you should see the following messages:
[CHECK-DEP]\>\>\> Analyzing the follow dependencies [\<SF_SCHEDULER setting\>]...[CHECK-DEP]\>\>\> Getting last run for analysis [\<ANALYSIS_X\>]...[CHECK-DEP]\>\>\> Last Case End-Time for analysis [\<LAST EXEC from LASTRUN\>] = (UTC) \<LAST EXEC LASTRUN\>[CHECK-DEP]\>\>\> Verifying against time [(UTC) \<CASE ENDTIME\>]...Dependent analyses not executed yet message:
[CHECK-DEP]\>\>\> Invalid time (UTC)! Last execution must be greater or equal. Exiting with not passed check...Dependent analyses already executed message:
[CHECK-DEP]\>\>\> Time (UTC) is ok! (LAST EXEC LASTRUN \>= \<CASE ENDTIME\>). Continue...Step 9: The Scheduler enters into a loop that can only be broken by the maximum amount of cases to be created/recovered at the time. The maximum number of loops can be configured by setting the 'MAXCASE' column of the SF_Scheduler table. When the counter of the cases is reached, Scheduler exits from the loop with the following message in the log:
[EXEC]\>\>\> Maximun execution loop reached! Breaking the loop...