A workflow is a list of instructions called Step objects. Each Step has an APISpec field which defines how the HTTP call must be made. This way it would be easy for you to create your OWN workflow automation and publishing modal!
There are 4 parts
Every workflow is made of a set of steps. Each step has n APISpec, that can be associated with additional configurations and retries.
defined the number of workers this task will need.
as defined above
input for the step
output from the step
step name fro identification
as defined above
define the URL to hit
define REST API methods here
All HTTP verbs (gfet, put, post
set a timeout for your API
Total number of retries to allow. Takes precedence over other counts
How many connection-related errors to retry on
How many times to retry on read errors.
How many redirects we allow
How many times to retry on bad status codes
How many times to retry on other errors
HTTP verbs to retry on
eg: ['GET', 'PUT', 'DELETE']
HTTP status codes to retry on.
eg: [413, 429, 503]
backoff factor to apply between attempts after second try
any float number
Whether to respect Retry-After header on status codes - [413, 429, 503]
a unique numeral identifier
plain text english identifier, name the workflow
this will be of type ScopeEnum (discussed below)
values can be 'workspace' or 'global'
defines what happens in the workflow
Mason workspace id
email id of the user
class ScopeEnum(str, Enum): workspace_scope = 'workspace' global_scope = 'global'
The main field of interest in a workflow definition is flow. It contains a list of one or more steps to be executed. In this case, we have a single step. Each step is named (in this case the name is auth). The name can be any unicode string chosen by the workflow author. The name of each step in the flow must be unique.
Each workflow has a global "state" available which is pre-populated with a set of fields. A step in the workflow can also populate different fields in the global state which other steps will have access to. These fields can be accessed in jinja templates. In the above workflow, you can see the following state fields in action -
SYSTEM_APIS - this will have a set of mason api urls prepopulated for use in the workflow. For example SYSTEM_APIS.credentials will resolve accordingly.
USER - this field will have information about the caller such as token, workspace_id, userid etc.
CURRENT_STEP - this is a transient field whose value depends on the state of the step under execution. It will have sub fields which are specific to the current step such as response & input.
The full list of all the fields available in the global state is in the Workflow State doc.
A default retry configuration can be set at the top level. It can also be overridden at the level of each step.
Updated about 2 months ago
Let's put this to action, in the user guide below you will find step-wise examples of making automation workflows.