13 WorkflowDescriptors

Each workflow configured in DELFT-FEWS must be registered in the WorkflowDescriptors configuration. This is required to identify the workflow to DELFT-FEWS. The configuration also sets some properties of the workflow.

The default name of the WorkflowDescriptors  is:  WorkflowDescriptors.xml. This file is located in the RegionConfigFiles folder.

Figure: Elements of the workflowDescriptor configuration.

workflowDescriptor

Root element of the WorkflowDescriptor. A new element is required for each workflow. Multiple instances may be defined.

Attributes:

• Id: Id of the workflow. This Id must be unique. Normally a string is used that gives some understanding of the role of the module (e.g. ImportExternal).
• name: Optional name for the module. Used for reference purposes only.
• visible: Boolean toggle to indicate if workflow is visible for selection in the manual forecast display. Dependent workflows (e.g. sub-workflows) should not be marked visible so that these cannot be run independently. Default is true.
• Forecast: Boolean flag to indicated if workflow is identified as a forecast. This should be the case for workflows with simulated time series as a results. Only Forecast workflows can be approved and made current. Import workflows of external data are not forecasts. Default is true.
• allowApprove. Boolean flag to indicate if workflow may be approved a-priori through manual forecast display (stand-alone only). Default is true.
• autoApprove. Boolean flag to indicate workflow should automatically be approved a-priori (stand-alone only). Default is false.
• autoSetSystemTime. Boolean flag to indicate workflow should automatically adjust the system time. When the workflow is completed and is fully or partly successful, the system time wil be set to the start time of the period written by this workflow.
  If the start time is not a valid time in accordance with the cardinal timestep, the next valid time wil be used.
  Default flag value is false. Applicable only on stand-alone.
• maxEnsembleParts: Positive integer. Determines in how many parts (i.e. forecasting shell instances available) at most the workflow can be split up to run in parallel for ensembles. Ensembles can/will only be split up if this element is specified and the number specified is larger than 1.
• timeOut: optional timeout that a workflow is allowed to run before the Forecasting Shell terminates it. This setting is independent of the master controller chaser. Therefore it makes only sense to specify a time out smaller than the master-controller chaser grace time.
• showWarningInLogCompletion: Boolean to report whether warning messages were logged during the execution of the workflow, default false.
• waterCoachDelay: Prevents simulated forecasts becoming available too early in water coach mode. The forecasts are finished in real life at time zero plus delay. The delay includes the run time and the time0 shift. When a forecast is scheduled at 7:00 am with a time0 of 0:00 am and the runs takes approximately an hour you should specify an delay of 8 hours. For external forecasts the delay is configured in the moduleInstanceDescriptors.xml
• runExpirytime: Used for runs of simulated timeseries to override expiry time from global properties DEFAULT_EXPIRY_DAYS. When timeseriesets expirytime is also configured, the minimum of runExpiryTime and the timeSeriesSets expirytime is used. Obsolete for import data since 2017.01.

Node (since 2019.01)

The workflows can be organised in a folder structure in the Manual Forecast Display with the node element. The workflow desctiptor ID's need to be added to the nodes. If this functionality is included in the workflowDescriptors, workflows that are not included in the node tree will not be visible anymore in the Manual Forecast Display.

<rootNode>
		<node name="Import">
			<workflowId>Import_Hydro_Observations</workflowId>
			<workflowId>Import_Forecasts</workflowId>
			<workflowId>Import_EarthObservation</workflowId>
			<workflowId>Import_Earth2Observe</workflowId>
			<workflowId>Import_HYCOM_All</workflowId>
			<workflowId>Import_WaveWatch3</workflowId>
		</node>
		<node name="Process">
			<workflowId>Create_GFS_Ensembles</workflowId>
			<workflowId>Copy_GFS_Grid</workflowId>
			<workflowId>Modify_GFS_Grid</workflowId>
		</node>
		<node name="Rest">
			<workflowId>Process_Operational_Grids</workflowId>
			<workflowId>WFlow_historic</workflowId>
			<workflowId>WFlow_forecast</workflowId>
			<workflowId>WFlow_E2O_historic</workflowId>
			<workflowId>Fractions_forecast</workflowId>
		</node>
	</rootNode>

ApprovalEventCode (since 2020.01)

ApprovalEventCode is user configured event code that is logged upon approving a forecast, instead of default event code “DataStore.NewCurrentRun” . ApprovalEventCode make it possible to log different approval event codes per workflow, so that different actions can be triggered by Master-Controller after approving particular forecast(s) . ApprovalEventCode can be any string that meets requirements of the event code pattern .

Use ‘ approvalEventCode’ to take more control over the triggering of the actions by Master_controller after the forecast approval .
Both workflows below do exactly the same forecast, but log different approval event code. Only the code FluvialForecast.Approved is used in Event Action Mapping (more info Event and Actions)
Master-Controller triggers any follow up action only when FluvialForecast becomes approved. FluvialForecastIntermediate can be run without any follow up actions.

<workflowDescriptor id="FluvialForecastIntermediate" forecast="true" visible="true" autoApprove="true">  
             <approvalEventCode>FluvialForecastIntermediate.Approved</approvalEventCode>
</workflowDescriptor>
<workflowDescriptor id="FluvialForecast" forecast="true" visible="true" autoApprove="true">  
             <approvalEventCode>FluvialForecast.Approved</approvalEventCode>
</workflowDescriptor>