# Page History

## Key

• This line was removed.
• Formatting was changed.

...

Example:

Code Block
language xml true
```<?xml version="1.0" encoding="UTF-8"?>
<workflow xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/workflow.xsd" version="1.1">
<activity>
<runIndependent>true</runIndependent>
<description>Description</description>
</activity>
</workflow>```

...

Functionality is available since 2017.02 for external historical data. Only works in combination with an archive connection as configured in SystemConfigFiles/Archives.xml

Anchor
 Workflow_FlagSource Workflow_FlagSource
defaultFlagSource

Optional element; Flag source that is used to write to the flagSourceColumn in an activity that is able to write a flag. Used for non missing values when no other flagSource is applied. The defaultFlagSource will be written in case no flag is changed and data is non missing. Typically this defaultFlagSource is set to be 'OK', and configured in CustomFlagSources configuration file.

...

Root element for the definition of one or more properties. Multiple entries can be defined. Properties can be externalize portions of a timeSeriesSet definitions (e.g. locationSetId) or parameter values from the module configuration file to the level of the workflow definition.

##### properties:string

property definition for a string data type.  Holds a key-attribute and a value-attribute, where the attribute value is replacing the $key$ as defined in a module config file.

...

Runs all members which id matches the specified expression  e.g specify ^Q.* to loop over all members that start with Q.

Info

Activities in a workflow or nested workflows may be called only once. This is to avoid mistakes through multiple calls to the same activity in different locations thus creating ambiguous results, or circular references in defining fallback activities.

...

Grouping to enforce sequential execution of multiple activities as they generally have data dependencies. Typically used in workflows where parallel activities are defined to clarify which activities have be to executed in sequence.

Figure 143  Elements of an Parallel Activity in the workflow.

...

The example below is complex in a different way as it uses properties to hand over catchment specific information to a report.

Code Block
language xml Usage of properties to add catchment specific information to a web-report
```<workflow version="1.1" xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/workflow.xsd">
<!--Create Calibration reports-->
<properties>
<string key="CATCHMENT" value="armidale"/>
<string key="CATCHMENT_NAME" value="Armidale"/>
<string key="BASIN" value="macleay"/>
<string key="STATE" value="NSW"/>
<string key="TIMEZONE" value="AET"/>
<string key="ENSEMBLE" value="OFFICIAL"/>
<string key="ENSMEMBER" value="URBS Final"/>
</properties>
<!--Compute -sub-catchment averaged data as sub-catchment data is not archived-->
<activity>
<runIndependent>true</runIndependent>
<moduleInstanceId>Processing_15m_Site_Calibration</moduleInstanceId>
</activity>
<activity>
<runIndependent>true</runIndependent>
<moduleInstanceId>Performance_15m_Calibration</moduleInstanceId>
</activity>
<activity>
<runIndependent>true</runIndependent>
<moduleInstanceId>Report_15m_Site_Calibration</moduleInstanceId>
</activity>
<activity>
<runIndependent>true</runIndependent>
<moduleInstanceId>Report_Catchment_Calibration</moduleInstanceId>
</activity>
</workflow>```

The following workflow example uses properties to make a apply the logic, encapsulated in general module config file, to a specific catchment. The second code block shows how some of the properties are used to make timeseriessets in the Rainfall_15m_Forecast module config file unique for the locations of a certain catchment.

Code Block
language xml Workflow defining property-values to apply general processing logic to a specific catchment
```<workflow xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/workflow.xsd" version="1.1">

<properties>
<string key="CATCHMENT" value="armidale"/>
<string key="BASIN" value="macleay"/>
<string key="ENSEMBLE" value="IFD"/>
<string key="ENSMEMBER" value="URBS Local"/>
</properties>
<activity>
<runIndependent>true</runIndependent>
<moduleInstanceId>armidale_Rainfall_Forecast</moduleInstanceId>
<moduleConfigFileName>Rainfall_15m_Forecast</moduleConfigFileName>
</activity>
<activity>
<runIndependent>true</runIndependent>
<workflowId>armidale_URBS_Catchment_Forecast</workflowId>
<ensemble>
<ensembleId>IFD</ensembleId>
<runInLoop>true</runInLoop>
</ensemble>
</activity>
</workflow>```

Code Block
language xml Property-keys to allow catchment specific timeseries definitions in the Rainfall_15m_Forecast module config file
```    <variable>
<variableId>ACCESS_G_subarea_3h</variableId>
<timeSeriesSet>
<moduleInstanceId>$CATCHMENT$_Rainfall_Forecast</moduleInstanceId>
<valueType>scalar</valueType>
<parameterId>P.nwp.fcst</parameterId>
<qualifierId>ACCESS_G</qualifierId>
<locationSetId>URBS_subareas.$CATCHMENT$</locationSetId>
<timeSeriesType>temporary</timeSeriesType>
<timeStep unit="hour" multiplier="3"/>
</timeSeriesSet>
</variable>```

Since 2015.01 it is possible to use these property keys in all elements of the timeSeriesSet including e.g. $TIME_SERIES_TYPE$ and $START_DAYS$

Code Block
```    <variable>
<variableId>Variable</variableId>
<timeSeriesSet>
<moduleInstanceId>import</moduleInstanceId>
<valueType>scalar</valueType
<parameterId>H.obs</parameterId>
<locationId>H-2001</locationId>
<timeSeriesType>$TIME_SERIES_TYPE$</timeSeriesType>
<timeStep unit="day"/> <relativeViewPeriod unit="day" start="$START_DAYS$" end="1"/>
</timeSeriesSet>
</variable>```

Example of a sub-workflow with parallel activities using properties defined at a higher level workflow

Code Block
language xml Sub-workflow using properties defined at top-level workflow
```<workflow xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews
http://fews.wldelft.nl/schemas/version1.0/workflow.xsd" version="1.1">
<parallel>
<activity logStartedAsDebug="true" logFinishedAsDebug="true">
<runIndependent>false</runIndependent>
<moduleInstanceId>RTCTools_KOT_Check_$RUNTYPE$</moduleInstanceId>
<moduleConfigFileName>RTCTools_Check_Qinc_Fx</moduleConfigFileName>
</activity>
<activity logStartedAsDebug="true" logFinishedAsDebug="true">
<runIndependent>false</runIndependent>
<moduleInstanceId>RTCTools_KOT_Check_$RUNTYPE$</moduleInstanceId>
<moduleConfigFileName>RTCTools_Check_QO_Seed</moduleConfigFileName>
</activity>
<activity logStartedAsDebug="true" logFinishedAsDebug="true">
<runIndependent>false</runIndependent>
<moduleInstanceId>RTCTools_KOT_Check_$RUNTYPE$</moduleInstanceId>
<moduleConfigFileName>RTCTools_Check_FB</moduleConfigFileName>
</activity>
</parallel>
</workflow>```

...

You can loop over a particular locationSet using the following config. In the ModuleInstance (e.g. exportActivity of a GeneralAdapter) in every 'loop' the $LOOP_LOCATION_ID$ tag will be replaced with the 'actual' locationId.

Code Block
language xml Sub-workflow using properties defined at top-level workflow
```<workflow xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews
<activity>
<runIndependent>true</runIndependent>
<moduleInstanceId>ModuleInstanceId</moduleInstanceId>
<loopLocationSetId>LocationSetId</loopLocationSetId>
</activity>```

...