As described in the section on workflow scheduling, Steep transforms a workflow to one or more process chains. A process chain is a sequential list of instructions that will be sent to Steep’s remote agents to execute processing services in a distributed environment.
Some of the properties specified in the table below are only available once Steep has
started executing a process chain (e.g.
startTime) or after the execution has
/processchains HTTP endpoint, which provides a list of process chains, omits some properties although they
are marked as required in the table below (e.g.
If you want to get all required properties, you have to use the
/processchains/:id HTTP endpoint.
Steep records each execution of a process chain in a separate ‘run’.
totalRuns specifies how often a process chain has been executed
(including any currently running execution). If a process chain has just been
created and still has the status
0, but as
soon as the status switches to
RUNNING, a new run is created and
is incremented to
1. If a process chain fails and is later retried, for
example, a new run will be created and
totalRuns will be
Requesting a process chain through the HTTP endpoints
always renders the latest run. The properties
autoResumeAfter depend on the actual run rendered (e.g.
different runs have different start times; or one run might have failed, while a
newer one might have succeeded or is still running, so their statuses are
different). If you want to list all runs of a process chain or retrieve
information about a specific run, use the
HTTP endpoints, respectively. The property
runNumber from the table below
specifies, which run out of
totalRuns is rendered.
An executable is part of a process chain. It describes how a processing service should be executed and with which parameters.
An argument is part of an executable.
An argument variable holds the value of an argument.
Process chain status
The following table shows the statuses a process chain can have: