A workflow consists of multiple elements, and each element is responsible for describing one aspect of the workflow. The workflow contains multiple steps which can be interlinked to define a more complex workflow. The workflow consists of variables, and you can provide the values at the time of execution.

The following diagram illustrates the relationship between the various elements of a workflow.

The top-level element is the workflow itself which contains a few mandatory elements.

The following table lists the mandatory elements.
Workflow Element Description
Name Name of the workflow. It is a non-empty value that you can use in RBAC filters.
Version Version of the workflow definition. This version is not used by VMware Telco Cloud Automation but helps the users to distinguish between the different workflow variants.
schemaVersion The version of the workflow used by VMware Telco Cloud Automation. This version configures the features available for one workflow. The possible values are:
  • 3.0: Current
  • 2.0: Deprecated
  • 1.0: Deprecated
Note: The support for 2.0 and 1.0 variants will be removed in the subsequent VMware Telco Cloud Automation releases.
id The id of the workflow is a conditionally mandatory element. The id is applicable only if the workflow is embedded within an NF/NS package where the identifier is used to match the pairs of workflows during the NF/NS upgrade scenarios.

Sample code snippet:

{ 

  "id": "testCrud1" 

  … 
}
Step A step is an action of the workflow that interacts with an external system. The information model is classified into two parts design-time, and runtime. The elements in design-time represent the definition of the workflow, and the elements in runtime represent a concrete execution of the workflow.

Following is the sample code snippet for the workflow elements, Name, Version, and SchemaVersion:

{ 

  "name": "Apache instantiate start workflow", 
  "version": "1.0 version", 
  "schemaVersion": "3.0", 

  … 
}

Data Types

Data types are used in various parts of the workflow to define the type of a particular element. Values that are not conforming to a specific data type cause design or runtime validation errors.

The following table lists the supported data types.
Data Type Description
String A UTF-8-character sequence. A string format can have the following values:
  • String: A character sequence without line breaks
  • Text: A character sequence with line breaks (\n)
  • Password: A base64 encoded value
Number A 32-bit integer.
Password A base 64 encoded string.
Boolean A logical value (true or false).
File Name of the file.
vimLocation Identifier of the VIM.
virtualMachine Name of the VDU on which the step is executed.
Text A text box that accepts a character sequence with line breaks.

Input

The workflow may optionally contain inputs that pass on the read-only information to a workflow at the time of execution. Inputs define the possible inputs (mandatory and default values) and their characteristics. Most workflows require a certain set of input parameters to run. For example, if a workflow resets a virtual machine, then the workflow needs to define an input with a virtual machine data type to allow the caller to control which virtual machine to restart.

The following table lists the fields of an input:
Input Field Description
Type A mandatory data type of the input.
Format An optional format of the data type.
Description: An optional non-empty description of the input.
DefaultValue An optional default value of the input.
Required An optional value of the input (defaults to false).
Note: If an input is required, then the value of the input will be provided. Inputs with a default value are not required.

Following is the sample code snippet for inputs:

{
  "inputs": {
    "in1": {
      "type": "string",
      "format": "password",
      "defaultValue": "bXlTZWNyZXQ=",
      "description" : "My special input 1"
    },
    "in2": {
      "type": "string",
      "defaultValue": "myInput"
    },
    "in3": {
      "type": "string",
      "required" : true
    },
    "in4": {
      "type": "string",
      "format" : "text"
    },
    "in5": {
      "type": "boolean",
      "defaultValue" : true
    },
    "in6": {
      "type": "number",
      "defaultValue" : 123
    },
    "in7": {
      "type": "number",
      "defaultValue" : 123.4
    },
    "in8": {
      "type": "password",
      "description" : "do not use deprecated",
      "defaultValue" : "bXlTZWNyZXQ="
    },
    "in9": {
      "type": "boolean",
      "defaultValue" : true 
    },
    "in10": {
      "type": "file",
      "defaultValue" : "myAttachmentName.txt"
    },
    "in4": {
      "type": "vimLocation",
      "defaultValue" : "25a1a262-715b-11ed-a1eb-0242ac120002"
   },
    "in4": {
       "type": "virtualMachine",
      "defaultValue" : "myVduName"
    }
  },
  …
}

Output

The output of a workflow is the result of workflow execution. Output parameters are set during the execution of the workflow. Output can be used by various LCM processes. For example, a pre-workflow that determines the location of the Network Repository Function (NRF) passes it on as an instantiation parameter (HELM input value) to the Access and Mobility Management Function (AMF).

The following table lists the various fields of an output.
Output Field Description
Type A mandatory data type of the output.
Format An optional format of the data type.
Description An optional non-empty description of the output.

The format of the outputs is identical to the inputs. However, in outputs, the attributes are not available, and only string, number, boolean, and virtual machine data types are used.

Following is the sample code snippet for outputs:

{
  "outputs": {
    "output1": {
      "type": "string",
      "format": "password",
      "defaultValue": "bXlTZWNyZXQ=",
      "description" : "My special output 1"
    },
    "output2": {
      "type": "boolean",
      "defaultValue" : true
    },
    "output3": {
      "type": "number",
      "defaultValue" : 123
    },
    "output4": {
      "type": "virtualMachine",
      "defaultValue" : "myVduName"
    }
  },
  …
}

Variables

The workflow may also contain variables. Variables are very similar to inputs. However, variables are not read-only and may change at the time of workflow execution. The variables may have user-defined input values or may be automatically assigned based on the context of the workflow execution. The vnfId variable is automatically assigned if the workflow runs on Network Function, and if the workflow runs on Network Service, the nsId variable is populated. If these two variables are defined, they have the string data type.

The following table lists the possible fields of the workflow variables.
Workflow Variable Field Description
Type A mandatory data type of the variable.
Format: An optional format of the data type.
Description: An optional non-empty description of the variable.
DefaultValue An optional default value of the variable.

Following is the sample code snippet for variables:

{
  "variables": {
    "variable1": {
      "type": "string",
      "format": "password",
      "defaultValue": "bXlTZWNyZXQ=",
      "description" : "My special variable 1"
    },
    "vnfId": {
      "type": "string",
      "description": "The identifier of the NF"
    },
    "nsId": {
      "type": "string",
      "description": "The identifier of the NS"
    }
  }
  …
}

Attachments

You can attach binary files or text files in the workflow definition. Attachments are stored in the workflow catalog, and the maximum file size is 5 MB. Attachments can be added to the standalone workflow through the UI or automatically assigned to the workflow if the workflow is embedded in an NF / NS package. If the workflow is embedded in an NS package, the files located in the Artifacts/scripts directory in CSAR are automatically attached to each workflow definition.

Therefore, if the CSAR contains the following files, the files are referred to by “script1.sh”, “script2.sh” or “subDir/script1.sh” in default values:

  • /Artifacts/scripts/script1.sh
  • /Artifacts/scripts/script2.sh
  • /Artifacts/scripts/subDir/script1.sh

When the workflow is created in the workflow catalog, the administrative elements are assigned to the workflow. These administrative elements control various operability aspects of the workflow; for example, RBAC, editability, and so on. You cannot define these attributes in the workflow template, but the system computes these attributes after the workflow is created.

The following table lists the elements of a variable.
Element of a Variable Description
Owner An entity in VMware Telco Cloud Automation that owns the workflow. The owner is the end user if the workflow is standalone or if the workflow is embedded NF/NS package.
CreationTime The time at which the workflow is created.
CreationUser Identifier of the user who created the workflow.
ReadOnly Determines if the workflow can be edited. If the workflow is created internally from the embedded workflow, then it is automatically assigned a false value.