Automation publisher workflow

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!

Workflow Syntax

There are 4 parts

  • step
  • APISpec
  • retry
  • workflow

Every workflow is made of a set of steps. Each step has n APISpec, that can be associated with additional configurations and retries.

The step

field

type

description

valid values

concurrency

int

defined the number of workers this task will need.

integer

apispec

APISpec

as defined above

input

str

input for the step

optional string

output

str

output from the step

optional string

name

str

step name fro identification

names of all the steps in a workflow must be unique

retry

Retry

as defined above

optional

The APISpec

field

type

description

valid values

url

str

define the URL to hit

method

str

define REST API methods here

All HTTP verbs (gfet, put, post

data

[Union[dict, str]]

Optional
The field value can be dict, str or None

headers

Optional[Union[dict, str]]

Optional
The field value can be dict, str or None

params

Optional[Union[dict, str]]

Optional
The field value can be dict, str or None

json_body

Optional[Union[dict, str]]

Optional
The field value can be dict, str or None

timeout

int

set a timeout for your API

integer

The retry

field

type

description

valid values

total

int

Total number of retries to allow. Takes precedence over other counts

any integer

connect

int

How many connection-related errors to retry on

any integer

read

int

How many times to retry on read errors.

any integer

redirect

int

How many redirects we allow

any integer

status

int

How many times to retry on bad status codes

any integer

other

int

How many times to retry on other errors

any integer

allowed_methods

List[str]

HTTP verbs to retry on

eg: ['GET', 'PUT', 'DELETE']

status_forcelist

List[int]

HTTP status codes to retry on.

eg: [413, 429, 503]

backoff_factor

float

backoff factor to apply between attempts after second try

any float number

raise_on_redirect

bool

True/ False

raise_on_status

bool

True/ False

respect_retry_after_header

bool

Whether to respect Retry-After header on status codes - [413, 429, 503]

True/False

The workflow

field

type

description

valid values

uid

Optional[UUID]

a unique numeral identifier

name

str

plain text english identifier, name the workflow

scope

ScopeEnum

this will be of type ScopeEnum (discussed below)

values can be 'workspace' or 'global'

steps

List[Step]

defines what happens in the workflow

workspace_id

UUID

Mason workspace id

user_id

EmailStr

email id of the user

created

datetime

Field(default_factory=datetime.utcnow)

updated

datetime

Field(default_factory=datetime.utcnow)

deleted

bool

True/ False

default_retry

Retry

Field(default_factory=Retry)
default_retry defines the default retry configuration for steps. It can be overriden by the retry field inside Step

class ScopeEnum(str, Enum):
  workspace_scope = 'workspace'
  global_scope = 'global'

Flow & Steps

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.

Workflow state

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.

Retry

A default retry configuration can be set at the top level. It can also be overridden at the level of each step.


What’s Next

Let's put this to action, in the user guide below you will find step-wise examples of making automation workflows.

Did this page help you?