...
Boolean flag to indicate if the activity is considered to be independent of other activities in the workflows. If the flag is set to "false" (default) then the failure of this activity will cause the complete workflow being considered as having failed. No further activities will be carried out. If the flag is set to "true", then failure of an activity will not cause the workflow to fail. The next activity in the workflow will also be attempted. An indication is given to the user in the Forecast Management display if one or more workflow activities have failed.
enabled
This feature is added since FEWS The <enabled> element (since 2017.02 and ) can be used to in- or exclude an activity in a workflow run. This feature is based on a location attribute. If you configure a modifier for this, the forecaster can in- or exclude activities (modules or sub-workflows) from a workflow run from the OC.
The enabled element contains a locationId and a location attributeId. The location attribute Id must be a boolean attribute that can be TRUE or FALSE. When the attribute value is TRUE 2 attributes:
- locationId
- attributeId, which is a BOOLEAN attribute for that location (i.e. TRUE or FALSE)
- when TRUE: the activity will be
...
- included,
- when
...
- FALSE: the activity will not be included.
Example below, for a full How To see: How To: configure <enabled> in Workflow based on location attributes run. The idea behind this feature is that the location attribute can be changed with a modifier, enabling the forecaster to exclude activities (modules or sub-workflows) from a workflow run.Example:
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<activity> <enabled locationId="CAP" attributeId="EXPORT"/> <moduleInstanceId>Export_CAP</moduleInstanceId> <description>Export CAP messages</description> </activity> </workflow>CAP" attributeId="EXPORT"/> <moduleInstanceId>Export_CAP</moduleInstanceId> <description>Export CAP messages</description> </activity> </workflow> |
enable
The <enable> element (since 2024.01) can be used in- or exclude an activity in a workflow, similar to the <enabled> element. However, this element is not coupled to location attributes, instead a boolean value is used, which can be hardcoded as in the example below or defined through a global property in the file global.properties.
| Code Block | ||
|---|---|---|
| ||
<activity>
<enable>true</enable>
<moduleInstanceId>Run_Model</moduleInstanceId>
</activity> |
Description
Optional field. If configured, the text will be displayed in the workflow navigator tree as mouse over label (tooltip).
...
Root element for the definition of one or more properties. Multiple entries can be defined. Properties can be externalize externalized portions of a timeSeriesSet definitions (e.g. locationSetId) or parameter values from the module configuration file to the level of the workflow definition.
...
When using forecastingShellCount = n every underlying loop is split into n parts. Every FS instance is running the same specified activity but skipping the part of the ensemble loop / location loop that is meant for an other FS instance. It is not allowed to start a nested parallel when you are in a ensemble/location loop parallel. Since 2024.01 it is possible to use a global property for the forecastingShellCount instead of a integer. This property may not reference a task property / whatif / modifier. The scheduling info will only be updated after a new config revision.
| Info | ||
|---|---|---|
| ||
Before 2019.02 if an existing scheduled workflow is redefined as a parallel workflow, it needs to be rescheduled to prevent errors. In the worst case situation the MC may become unavailable. |
...
Explicit deletes temporary series. At the end workflow partition or the end of the workflow temporary series are automatically deleted. Deleting specified module
instances earlier prevents the temporary series are flushed to disk for no use when they are still in the memory buffer. Time series that are explicitly deleted in another
workflow partition then the partition were they were created are always flushed to the database. This makes it possible to use temporary time series even when the workflows
continues on a different forecasting shell. When the workflow terminates or completes all temporary series for the run are deleted from the database