Skip to content

Job Manager Overview

The aim of this section is to describe the best possible manner in which to control the Job Manager for authoring well-designed jobs, batches of actions that are executed as a single unit of work, executed either as an ad-hoc job or a job that is executed on a scheduled basis. Jobs are an integral part of nearly all real-time or operational applications of the MIKE Workbench.

Although many of the other manager documents aim at programming with or for the Workbench, this section focuses on applying existing functionality and is therefore closer to end-user documentation. That said, authoring jobs is in many ways similar to programming, perhaps at a more abstract level through dragging and dropping functionality components from a palette up to a workflow-oriented structure, but it still deals with designing a flow of actions and implementing them through writing jobs in a language specifically for jobs.

This section document consists of three sections, with the first section defining the anatomy of a job, the structure and the most important types of elements. The second part incorporates working with jobs, consisting of answers to a series of frequently occurring questions and finally the document ends with a section on how the user interface supports the user in working with jobs.

Job environment

Jobs within the MIKE Workbench are used as a means to batch commands together and have them executed or scheduled for execution as a single work unit. A scenario where jobs are very useful is with automatic and scheduled execution of model simulations. It is often not enough to just execute the actual simulation but could require pre-processing of input time series for the simulation and post-processing to extract information from the simulation results, check key indicators and possibly submit alerts and notifications

The main part of this section describes jobs from an XML perspective. XML is the source code format for jobs. This does not imply that user will have to manually write the XML, all job authoring as well as job execution happens from a graphical user interface. The last section in this document describes how to use the user interface but the job concepts are better explained from a source code oriented perspective.

A job is an XML structure that contains a list of tasks that are executed in a pre-defined order. The tasks typically execute both well-defined and atomic actions like for example, importing a time series to the Workbench database, running a scenario or performing a GIS zonal statistics analysis. The user defines the execution order of the tasks through targets where a target is simply a list of tasks. Execution-wise targets can depend on each other and thus form a semi-hierarchical structure.

Listing 1 below shows the content of a simple job that imports a time series from a DFS0 file, finds the median and finally writes that value to a disk file.

<?xml version="1.0" encoding="utf-8"?>
<Project 
    DefaultTargets="MyTarget" 
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003" 
    ToolsVersion="4.0">
    <Import Project="$(DSSBIN)\DHI.Solutions.JobManager.Tasks.Targets" />
    <PropertyGroup>
                                                            <!-- # 1 -->
        <Property>Quantile</Property>                                   
        <ProviderName xmlns="">MO Job Service Provider</ProviderName>
    </PropertyGroup>
    <ItemGroup></ItemGroup>
    <Target Name="MyTarget">                                <!-- # 2 -->
                                                            <!-- # 3 -->
        <ImportTimeseriesFromDFS0                                       
            DestinationGroup="/MyGroup" 
            SourceFile="c:\Temp\WaterLevels1.dfs0" 
            Overwrite="True" />
                                                            <!-- # 4 -->
        <CalculateTimeseriesQuantile 
            Timeseries="/MyTimeseries/Drogden: WaterLevels1" 
            Fraction="0.5">
                                                            <!-- # 6 -->
            <Output 
                TaskParameter="Quantile" 
                PropertyName="MyProperty" />
        </CalculateTimeseriesQuantile>
                                                            <!-- # 5 -->
        <WriteLinesToFile 
            File="C:\Temp\Quantile.txt" 
            Lines="$(Label) = $(MyProperty)"
            Overwrite="True" />
    </Target>
</Project>
Listing 1 sample job content

The following section describes targets, tasks and properties as well as task input and output in more detail.

The main points of interest that should be noted from the listing are:

  • Definition of job properties (point #1) which are key/value pairs that can be used

  • Definition of a job target (point #2) which are containers for related tasks

  • Definition of job tasks (point #3, #4 and #5) which are units of work.

These three element types, which basically constitute the vast majority of tasks, will be described in more detail in the sections that follow.

Figure 1 below displays how the same job appears in the MIKE Workbench user interface. Notice how the main window in the user interface shows the target and tasks in a tree-like structure, while the attributes are displayed as standard MIKE Workbench properties.

Figure 1 Sample job seen from the user interface

What is a target?

A target is nothing more than a grouping mechanism for tasks and is defined by the following attributes:

  • A name

  • An optional semicolon-separated list of other targets that need to be successfully executed before execution of the target can commence

  • An optional condition that determines under which circumstances the target shall be executed.

The last two types of attributes are discussed in more detail in the Working with Jobs section later in this document.

The formal target XML format is shown in Listing 2.

    <!-- ... -->
    <Target 
        Name="user-specified-name"
        DependsOnTarget="list-of-targets">
        <!-- ... -->
    </Target>
    <!-- ... -->
Listing 2 Target XML format

The name attribute is mandatory while the DependsOnTargets attribute is optional. See more about the latter in the section How to have targets depending on each other?

The user defines the above attributes when adding the target to the job through the Job Manager's user interface.

What is a task?

A task can be compared to a subroutine in a programming language - it has some input parameters, performs a well-defined action, can have output parameters and returns a status value indicating whether the action has been successfully executed.

In itself a task is a piece of binary code implemented as a C# class or other Microsoft .NET programming language. The Workbench comes with a long list of tasks for managing time series, scenarios, spreadsheets, disk files etc. Solution implementing projects can easily add their own custom-made tasks to this list. Implementing a task is typically a very simple programming function. It is even possible to create a Workbench embedded script and have this executed as part of a job. In this way, practically all the functionality provided by the Workbench is available when setting up jobs.

The following should be noted from the example in Listing 1:

  • How the task ImportTimeseries at point 1 specifies the input as task properties. In this case the SourceFile and DestinationGroup properties define the time series that will be imported and the path to where it shall be inserted in the database.

  • How the MaximumTimeseriesValue task has one input property, the path to the newly imported time series and one output property (or output element) which will hold the maximum value of the time series when the task has executed.

  • How the WriteLinesToFile task writes the output value from the previous executed task to a disk file.

The formal XML syntax is shown in Listing 3 below and is exemplified in Listing 1.

    <!-- ... -->
    <Task-name
        Attribute-1="value"
        Attribute-2="value"
        ContinueOnError="true or false"
        Condition="user-expression">
        <!-- ... -->
    </Target>
Listing 3 Task XML format

Note that a task can:

  • Have zero or more task input parameter attributes, some being mandatory and some optional.

  • Have zero or more output elements which can be transformed into job properties, as shown in the example in

  • Have an optional Condition processing instruction that determines under which circumstances the target will be executed. See section How to conditionally execute targets for detailed information.

  • Have an optional ContinueOnError processing instruction that determines if the job will halt or continue should the task fail. See Listing 12 Workaround for passing information between targets with CallTarget.

  • The calling target Target1 writes the Prop1 property to a file which is then read by Target2. It is not elegant but gets the job done.

  • Continue despite failing tasks for detailed instructions.

The last three types of attributes are discussed in more detail in the Working with Jobs section later in this document.

What is a property?

A property defines a value associated with a name. Simply put, it is a key/value pair. The example shown in Listing 1 defines a property in the PropertyGroup and uses it in the WriteLinesToFile task.

Properties are typically defined through property groups as shown in Listing 1 but can also be defined from task output parameters as shown at point #6 in the same listing. Here the CalculateTimeseriesQuantile task has an output parameter named Quantile that is being transformed into a property MyProperty through the job Output element.