A workflow in detail

Overview

While a step contains a self-contained action, sometimes it makes sense to split up a more complicated use case into multiple steps, run in sequence. That's where workflows come in. Steps are the building blocks of workflows, and can be chained together to accomplish more complex tasks.

Building

Workflows are created much the same as steps, via the web UI or CLI. In both cases, it is necessary to provide a name and a workflow definition (in JSON).

An example workflow definition:

[
  {
    "step": "collect_data:latest"
  },
  {
    "step": "investigate:2",
    "forEach": "$.response_id"
  },
  {
    "step": "analyze_results"
  }
]

A workflow is simply a sequence of steps, each of which provides its output as input to the following step. The input to the workflow is provided as input to the first step, and the output of the last step is the output of the workflow as a whole.

Note the highlighted line: this indicates 'fan-out' behavior, where the previous step outputs a list of response_id objects, and the next step then runs multiple times (concurrently) with each separate response_id as the input for a run of investigate:2. The outputs for all of those runs are then brought back into a single list of objects and passed together as input to the third step.

note

Each step is referred to by a tag or a particular version. If a step is called without a tag or version (as in the third step above), the deployed version of the step is chosen by default.

Running

Running a workflow is the same running an individual step: invoke it via the CLI or UI, or else via its API endpoint (https://api.sandgarden.com/workflow-name:version-or-tag). As input, pass the JSON data that the first workflow step is expecting.

Next steps

Once you have a workflow ready to go, it's time to productionize it:

• Apply tags to provide a stable API endpoint for your production applications
• Build test suites to track your workflow's effectiveness and quickly recognize and remediate regressions