First steps with automation

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.