The workflow service allows to define tasks and workflows, in order for workflows to be managed and executed in the cloud environment. The goal of the workflow management service is to support business processes (which includes tasks, their execution and its order, dependencies, report generation, etc), rather than building or managing services and infrastructure stacks to run a service or application (which is a purpose of the infrastructure orchestration tools).
Most business processes consist of multiple distinct interconnected steps that need to be executed in a particular order. A user can describe a business process as a set of tasks and their transitions. After that, it is possible to upload such a description to the service, which will take care of state management, the correct execution order, parallelism, synchronization, and high availability.
Workflow management service is based on Openstack service called "Mistral". This documentation does not aim to provide a full description of the workflow and task definition syntax, so you can refer to the available online documentation like this guide.
Before discussing the workflow management functionality, let's review the terminology used in the platform (and this document).
Workflow is a set of task, used to reflect a business process. On the platform, the workflow object is created when the user uploads a Workflow definition - which is a text description in language that platform can interpret and execute. Often times, workflows are designed to accept Inputs - such as object names or resource IDs that the workflow may refer to.
Workflows may be executed either manually (by the user), or by creating a trigger. The trigger has schedule attached, which will control when the workflow is executed. A trigger schedule uses standard "cron" pattern format, where which consist of a 5 number string, where the number can be also substituted by a "star" symbol. For example, 43 7 * * 5 is a valid cron pattern.
The schedule pattern is used to determine when to trigger the execution, and is interpreted as the following:
Any number can be also substituted with * symbol - meaning "no specific value". Therefore, the platform will interpret the pattern above 43 7 * * 5 like "Execute weekly - every Friday, at 7:43". Another pattern 56 7 15 * * means "Execute once a month, every 15th of the month, at 7:56".
Note that the scheduler operates by the UTC timezone (which may be different from your local timezone).
A workflow execution is an object that stores results of a specific workflow run. As a workflow is constructed of tasks, the execution contains status of these tasks. Each status shows Outputs (information printed by the task), and State info - it can be useful for the workflow troubleshooting.
To create a new workflow, click on the "Workflows" section in the left-hand navigation menu. Then, click the "Create workflow" button.
From that screen, you have choice of either uploading your own workflow definition (a YAML file), or creating a workflow from a template. The portal offers a number of simple workflows as templates, to perform routine asks such as instance creation or deletion - you can use those templates either as a starting point to create your own workflow, or for educational purposes.
Once workflow is created, you can execute it - either immediately (pressing "Execute" button or selecting corresponding action menu), or by creating a trigger with schedule. Either way, if the workflow contains any input parameters, you will be requested to provide that input.
Once execution is completed, you can see the execution results in the corresponding section of the workflow.
Also, at any time you can modify the workflow definition directly in the web browser. Once modifications are completed, the workflow definition in the platform will be replaced with the new one.
As far as the billing concerned, the workflow executions are free of charge. However, if the workflow creates any resources (such as instances or volumes), they will be billed accordingly
Workflow definitions are based on YAML syntax, with YAQL query language extensions. The extensions allow runtime evaluation of the results received from the platform, and thus make decisions based on the values.
For more information about supported workflow definition syntax, please see this documentation link.