...
The live forecasting system can be scheduled to run workflows as a consequence of a log event generated by the system. This facility is used to enhance forecasting, or to export current forecast data on a new forecast becoming available.
This can only be done by suitably authorised users, and should follow a carefully defined scheduling plan. These users must have access to the admin interface tool (see Admin Interface manual).
A run that is to be enhanced must have already been submitted to the Master Controller and available in the Scheduled Forecasting Lists. The run is identified by its tag available in that list.
The actions that can be defined are;
- Resuming a suspended task
- Suspending a task
- Changing of scheduling interval of a task (and resuming the task if required)
- Submitting a single run of a task
For each an appropriate action configuration must be defined.
The procedure in defining an action config is.
- Open the Admin interface.
- Select the Workflow and FSS's item
- Select Event and Action Configuration .
- Select Upload New Action Configuration . This is an XML file that describes the action to be taken. It includes the tag that is defined in the Scheduled Forecast list. This must be identical (case sensitive) for a match to be made. Examples for the four types of actions are given below.
- Submit the Action Config.
- Select Event Action Mappings item
- Select Create New Action Event Mapping
- Enter the Event Code and select the Action Configuration Id for the configuration just created.
- Select submit.
NOTE: when deleting action configurations, the Action Event Mapping must be deleted first due to relations in the database.
Example of Action Config to resume a suspended task
No Format |
---|
<?xml version="1.0" encoding="UTF-8"?>
<actionxml type="task">
<enhance>
<tag name="AIRE_FORECAST"/>
<resume/>
</enhance>
</actionxml>
|
Example of Action Config to suspend a task
No Format |
---|
<?xml version="1.0" encoding="UTF-8"?>
<actionxml type="task">
<enhance>
<tag name="AIRE_FORECAST"/>
<suspend/>
</enhance>
</actionxml>
|
Example of Action Config to enhance a task
No Format |
---|
<?xml version="1.0" encoding="UTF-8"?>
<actionxml type="task">
<enhance>
<tag name="EDEN_FORECAST"/>
<repeatinterval interval="3600"/>
</enhance>
</actionxml>
|
Example of Action Config to run one instance of a task
No Format |
---|
<?xml version="1.0" encoding="UTF-8"?>
<actionxml type="task">
<oneoff>
<cardinaltime interval="900" reference="2004-01-01T00:00:00.000+00:00"/>
<tag name="EXPORT_CURRENT"/>
</oneoff>
</actionxml>
|
Note1: a one off task requires a cardinal time step and a reference time to establish a correct T0 for the run. The new T0 will be the latest valid T0 for the specified cardinal time step. Suppose a task is triggered at 11:59 GMT with a 3 hour cardinal time-step from midnight, T0 will become 09:00 GMT, when triggered at 12:00 GMT, T0 will become 12:00 GMT. The cardinal time step is important as it also controls how often the master controller will run an instance of the task if triggered by an event. It will only run once every cardinal timestep, even though there are multiple events in that period.
Note2: It is recommended to use taskTags and workflowIds that are uniquely identifiable by their first 23 characters since those parts of the taskTag and workflowId are used for checking whether a task has already been triggered for a specific T0.
Note3: It is recommended to set the interval to 1 second if the action should be executed for every event code (e.g. in the case of sending alert messages), but should be increased if it is not desirable to execute several workflows in a short period (e.g. the case of creating web reports). It also needs the "template task" with the relevant tag scheduled (in suspended mode) as a single/one-off task.
Dual MC with failover mode triggers suspended tasks with runOnFailOver from remote MC
Since 2015.01 suspended one-off tasks can be triggered by failover (both manual and automatic failover).
For instance when the duty master-controller has a suspended one-off task prepared which is available via MC-Synchronisation at the other MC, then the second MC can trigger the duty Mc's task when a similar event-action mapping is available in the second MC.
E.g. MC00 is the duty MC and MC01 the backup. On both MCs there are frequently running import tasks both generating TASKRUN:Complete.ImportExternal. One suspended task one-off task BigCalculation has been prepared at the MC00 with the runOnFailOver option active.For MC01 no such task is prepared.
1. When MC00 is running fine, only MC00 triggers the BigCalculation task, MC01 logs that an event is processed but could not find a task.
2. MC00 is put in manual failover -> both MC00 and MC01 trigger BigCalculation task.
3. MC00 is restored from manual failover -> only MC00 triggers BigCalculation task.
4. MC00 is brought down -> only MC01 triggers BigCalculation task.
5. MC00 is restarted -> only MC00 triggers BigCalculation task.
6. MC00 is brought down by shutting down all FSSs -> only MC01 triggers BigCalculation task.
7. all MC00 FSSs are restarted-> only MC00 triggers BigCalculation task.
Related information on Event-codes
See also event-codes
Children Display |
---|