6.1 Workflow

Workflow definitions and definition examples are provided below. Workflow definitions are categorized into two main parts: A part that defines the overall workflow and a part that defines the individual activities. For descriptions of workflows, see “Workflow” and “Designing a workflow”.

(Table) Workflow definition

Label				Default value	Required	Description
apiVersion:				1.0	Yes	API version
kind:					Yes	Specify "workflow" for workflows
type:					No	Only "resource" can be specified for workflows
name:					Yes	Internal name of the Workflow definition. Specify the directory name for this YAML file. The characters that can be input in name are as follows. Single-byte alphanumeric character: a-z A-Z 0-9 Single-byte symbol: _ -
label:					Yes	YAML file display name
includes:					No	List the related YAML files for use in this YAML file
	- kind:				Yes	Type of YAML file to be loaded
	name:				Yes	Internal name of the YAML file to be loaded
description:					No	Detailed description
parameters:					No	Workflow parameters. Add using JSON Schema.
steps:					No	Define the workflow steps. Use to display the progress of a task.
	- name:				No	Step name
	label:				No	Step display name
	description:				No	Detailed description of step
(workflow model):					Yes	Define workflows. Describe the contents of workflow models that can be defined with StackStorm. For details, see "(Table) Workflow model"
	(task model):				Yes	Define activities. Describe the contents of task models that can be defined with StackStorm. For details, see "(Table) Task model"
		role:			No	Define the roles that can execute each activity. An example is provided below. Example: tasks: mytask: action: core.ask role: "Service Desk Agent"
		group:			No	Define the groups that can execute each activity. The specified groups will be automatically assigned to this activity.
		requirements:			No	Requirements for this activity
			skillset:		No	Skill set required to execute this activity. For details, see "Skill management" and "Skill, Skillset".
		ui:			No	The UI to be displayed when executing this activity. "core.noop" must be specified as the action type for the step displayed on the first window of the workflow. For all other steps, specify "core.ask" as the action type.
		step:			No	Name of the step to which this activity belongs
		label:			No	Display name

The workflow model above uses the same workflow model defined with StackStorm.
The workflow model defined in StackStorm is provided below.
For more information, see the official StackStorm homepage.
https://docs.stackstorm.com/3.7/orquesta/languages/orquesta.html#workflow-model

Notes Notes

The first window of the workflow is displayed when you open a new workflow from the service catalog window or when you open a new or unstarted workflow. When a workflow is executed from "Work item management functions", the task on the first window navigates to the next task without waiting for user input. Therefore, the group and role settings specified for "task" on the first window will apply when you open a new or unstarted workflow.
If you specify multiple UIs within a single workflow, the UI versions used within the workflow definition must be the same. For details on the UI versions, see "UI version".

(Table) Workflow model

Label	Required	Description
version:	Yes	Workflow definition format version
input:	No	Inputs for workflows
vars:	No	Defines a list of variables that can be used in the workflow
tasks:	Yes	Defines activities that constitute the workflow
output:	No	Defines a list of variables output from the workflow

Description of what can be added in “Task model” are provided below.
Ops I uses the same “task model” as StackStorm.
For more information, see the official StackStorm homepage.
https://docs.stackstorm.com/3.7/orquesta/languages/orquesta.html#task-model

(Table) Task model

Label			Required	Description
(taskname):			Yes	Assign a name to each activity and define the following for each.
	delay:		No	Number of seconds activity execution is delayed
	join:		No	Define the specification for starting an activity when there is an activity running in parallel in the previous stage. Example: Start when 3/3 of the activities in the previous stage are completed, or start when 2/3 of the activities in the previous stage are completed.
	action:		No	Define what is executed by an activity. For a list of what can be used, see below "(Table) List of actions (StackStorm components)" "(Table) List of actions (provided Ops I components)" "(Table) List of actions (provided Ops I components for JP1/AJS3 coordination)" "(Table) List of actions (provided Ops I components for JP1/IM coordination)"
	input:		No	List of inputs used in the task
	retry:		No	Definition for retrying activities. For details of attributes that can be used, see "(Table) Attributes that can be used with retry"
	next:		No	The activity to be executed next. For details of attributes that can be used, see "(Table) Attributes that can be used with next"
	subflow:		No	If specified, execute as a subflow.
		type:	Yes	Subflow type Specify one of the following values. "static": Create the context (schedule) when the source flow for start-up is saved "dynamic": Create the context (schedule) when the subflow is executed

Ops I users can use the following actions.

The StackStorm components that can be used by Ops I users when defining actions are detailed below.
For more information, see the official StackStorm homepage.
https://docs.stackstorm.com/3.7/actions.html

(Table) List of actions (StackStorm components)

Action

Description

core.ask

Wait for input from user.

core.http

Send HTTP request.

core.noop

Do nothing.

core.sendmail

Send email.

core.local

Execute a Linux command on the local host.

vault.read

Obtain secret information registered in the secret.
Use when you want to obtain secret information from secret management.
If using vault.read, it is necessary to set the following parameters.

Parameters	Required	Type	Description
path	Yes	String	Specify the path in which the secret information is stored.

vault.read return values are as below.

Parameters	Required	Type	Description
result.data.secret information key name	Yes	String	Secret information key name

(Table) Attributes that can be used with retry

Label	Required	Description
when:	No	Conditions for executing retry
count:	Yes	Number of retries
delay:	No	Number of seconds between retries

(Table) Attributes that can be used with next

Label	Required	Description
when:	No	Conditions for navigating
publish:	No	Value to showing in context
do:	No	The next task to be called when conditions are satisfied

apiVersion: 1.0
kind: workflow
type: resource
name: create_vm_wf
label: VM loan application
description: The workflow for applying to loan VM for demo purposes

includes:
  - kind: ui
    name: create_vm_ui_00
  - kind: ui
    name: create_vm_ui_01
  - kind: ui
    name: create_vm_ui_02
  - kind: ui
    name: create_vm_ui_04
  - kind: ui
    name: create_vm_ui_05

version: 1.0

steps:
  - name: create_vm_wf_00_step
    label: start
    description: start
  - name: create_vm_wf_01_step
    label: apply
    description: apply
  - name: create_vm_wf_02_step
    label: check application contents
    description: check application contents
  - name: create_vm_wf_03_step
    label: VM generation
    description: VM generation
  - name: create_vm_wf_04_step
    label: check VM generation
    description: check VM generation
  - name: create_vm_wf_05_step
    label: authorize
    description: authorize

tasks:
  start:
    action: core.noop
    ui: create_vm_ui_00
    step: create_vm_wf_00_step
    next:
      - when: <% succeeded() %>
        do: create_vm_wf_01
      - when: <% failed() %>
        do: fail

  create_vm_wf_01:
    label: application
    action: core.ask
    ui: create_vm_ui_01
    step: create_vm_wf_01_step
    next:
      - when: <% succeeded() %>
        do: create_vm_wf_02
      - when: <% failed() %>
        do: fail

  create_vm_wf_02:
    label: check application contents
    action: core.ask
    ui: create_vm_ui_02
    step: create_vm_wf_02_step
    role: ope-team
    input:
      schema:
        type: object
        properties:
          oi_response:
            type: string
            required: true
    next:
      - when: <% result().response.oi_response = accept %>
        do: create_vm_wf_03
      - when: <% result().response.oi_response = reject %>
        do: create_vm_wf_01
      - when: <% failed() %>
        do: fail

  create_vm_wf_03:
    label: VM generation
    action: core.noop
    step: create_vm_wf_03_step
    next:
      - when: <% succeeded() %>
        do: create_vm_wf_04
      - when: <% failed() %>
        do: fail

(omitted)

  create_vm_wf_05:
    label: authorize
    action: core.ask
    ui: create_vm_ui_05
    role: ope-team
    step: create_vm_wf_05_step
    input:
      schema:
        type: object
        properties:
          oi_response:
            type: string
            required: true
    next:
      - when: <% result().response.oi_response = accept %>
        do: finish
      - when: <% result().response.oi_response = reject %>
        do: create_vm_wf_04
      - when: <% failed() %>
        do: fail

  finish:
    action: core.noop

Those parts that are followed by similar sections are omitted and marked as “(Omitted)”.

Section structure

6.1.1 Provided Ops I components