Workflow definitions (2.0)

Workflows are defined using YAML. The schema for a workflow can be found in the engine's repository (workflow/workflow-schema.yaml). It can be used as a schema in an editor using a suitable URL. As an example, here's the URL for this version: -

• https://raw.githubusercontent.com/InformaticsMatters/squonk2-data-manager-workflow-engine/refs/heads/2.0/workflow/workflow-schema.yaml

  What follows is a discussion of workflows for version 2.0 of the workflow engine. You can find a number of example workflows in the engine repository's test/workflow-definitions directory.

In general, a workflow definition requires a declaration of the following: -

1. Information
2. Variables
3. Variable Mapping
4. Steps

Information

All workflows need an information section, typically found at the start of the definition. The supported root-level properties are described in the following table: -

Property	Type	Description
kind	String	A constant value that needs to be set to DataManagerWorkflow that will not change in future engine versions
kind-version	String	An enum string value that needs to be set to 2025.2 for version 2.0
name	String	The workflow name. An RFC1035 label name compliant string. Essentially up to 64 lower-case letters, digits and hyphens (not ending with -)
description	String	An optional free-format text property that provides the user with a high-level description of the workflow

Here's an example: -

---
kind: DataManagerWorkflow
kind-version: "2025.2"
name: nop-fail
description: >-
  A workflow with one step that fails

Variables

An optional (although typically always present) root-level property variables declares all the inputs, outputs, and options a user is expected to provide when they execute the workflow.

The workflow's schema does not cover this section, its structure is defined by the Data Manager Job definitions schema located in our squonk2-data-manager-job-decoder repository. The workflow engine currently does not use this section, it is present to simplify UI development by allowing it to reuse variable logic used when launching Jobs.

Variable Mapping

A workflow that contains variables (and all of them do) must contain a root-level variable-mapping property. This is a structure that defines the mapping of workflow variable to the variables of the individual Jobs within the workflow. There are sections for inputs, ouptuts, and options.

Inputs

It may seem to duplicate values form the variables section. inputs is an array that simply identifies input variable names used somewhere within the workflow. It's a temporary structure in 2.0 to simplify UI development by separating workflow semantics from Job execution.

Here's an example: -

variable-mapping:
  inputs:
  - name: input-1.sdf
  - name: input-2.sdf

Outputs

Options

Steps