Workflow Step Input

Step Input

A step type can have any of the following input:

NOOP: Empty step without any action
VRO_SSH: Execute commands or scripts through an SSH connection
VRO_SCP: Copy the file to a remote location through SCP
VRO_CUSTOM: Execute a custom vRO workflow
VRO_EXEC: Execute a command or script through VM tools
JavaScript: Execute a Java Script to manipulate inputs
K8S: Execute a script in a POD with access to the Kubernetes
API NETCONF: Execute Netconf configuration over a remote target
TCA_SSH: Execute commands or scripts through an SSH connection
TCA_SCP: Copy the file to a remote location through SCP
TCA_EXEC: Execute a command or script through VM tools

NOOP

This value is used to create a decision point in a workflow without executing a step that has an external side effect; for example, connecting a VM through SSH. Regardless of the number of inputs provided, the inputs are discarded, and no outputs are provided.

The following is a sample code snippet:

{ 
  "inputs": { 
    "inputMode" : { ... } 
  }, 
  "startStepId": "stepId1", 
  "steps": { 
    "stepId1": { 
      "type" : "NOOP", 
      "conditions": [ 
        { 
          "name": "inputMode", 
          "comparator": "equals", 
          "value": "active", 
          "nextStepId": "stepIdActive" 
        }, 
        { 
          "name": "inputMode", 
          "comparator": "passive", 
          "value": "active", 
          "nextStepId": "stepIdPassive" 
        } 
      ] 
    }, 
    "stepIdActive": { ... }, 
    "stepIdPassive": { ... } 
  }, 
  ... 
}

VRO_SSH

You can use the vRO SSH to execute the SSH commands on external entities, such as NFs and routers. The SSH connection from the TCP perspective originates from the vRO instance to the target. Connectivity is established between vRO and the external system. The vRO step that implements the SSH command execution is called SSH Command and can be inspected by logging into vRO.

The following table lists the vRO SSH step input values.


Name	Type	Mandatory	Note
`cmd`	string	Yes	Script to be executed.
`hostNameOrIP`	string	Yes	IP address or DNS name of the target system.
`username`	string	Yes	Username to be used.
`password`	string with password format	Yes	Password to be used.
`port`	number	No defaults to 22	TCP port of the SSH service.
`passwordAuthentication`	boolean	No defaults to true
`encoding`	string	No defaults to utf-8	Terminal encoding to be used.

If the script to be executed is very long, you can use the vRO SCP action to transfer the script to be executed to the target.

The usage of the SSH step is illustrated with the following template fragment:

{ 
  "inputs": { 
    "target": { 
      "type": "string", 
      "required": true 
    }, 
    "password": { 
      "type": "string", 
      "foramt" : "password", 
      "required": true 
    } 
  }, 
  "steps": { 
    "stepId1": { 
      "type": "VRO_SSH", 
      "inBindings": { 
        "username": { 
          "type": "string", 
          "defaultValue": "root" 
        }, 
        "password": { 
          "type": "password", 
          "exportName": "password" 
        }, 
        "port": { 
          "type": "number", 
          "defaultValue": "22" 
        }, 
        "cmd": { 
          "type": "string", 
          "defaultValue": "uptime" 
        }, 
        "passwordAuthentication": { 
          "type": "boolean", 
          "defaultValue": true 
        }, 
        "hostNameOrIP": { 
          "type": "string", 
          "exportName": "target" 
        }, 
        "encoding": { 
          "type": "string", 
          "defaultValue": "utf-8" 
        } 
      }, 
      "outBindings": { 
        "out_result": { 
          "name": "result", 
          "type": "string" 
        } 
      } 
    } 
  }, 
  "outputs": { 
    "out_result": { 
      "type": "string" 
    } 
  }, 

  … 
}

vRO_SCP

You can use the vRO SCP workflow to transfer the file to external systems, such as NF and router, using the SCP protocol. The vRO SCP workflow is executed using vRO. The SSH connection from the TCP perspective originates from the vRO instance to the target. Connectivity between vRO and the is established. The vRO workflow that implements the SCP is called File Upload and can be inspected by logging into vRO.

The following table lists the step and the corresponding input values.


Name	Type	Mandatory	Note
`inFile`	file	Yes	Name of the attachment to be transferred.
`destinationFileName`	string	No defaults to the name of the attachment	Name of the file to which the file is copied.
`workingDirectory`	string	Yes	The path where the file is copied.
`ip`	string	Yes	The IP or DNS name of the target system.
`username`	string	Yes	The username to be used.
`password`	string with password format	Yes	Password to be used.

The following workflow template fragment illustrates the usage of the vRO SCP step:

{ 
  "inputs": { 
    "target": { 
      "type": "string", 
      "required": true 
    }, 
    "password": { 
      "type": "string", 
      "format": "password", 
      "required": true 
    } 
  }, 
  "steps": { 
    "stepId1": { 
      "type": "VRO_SCP", 
      "inBindings": { 
        "inFile": { 
          "type": "file", 
          "defaultValue": "attachmentName.txt" 
        }, 
        "username": { 
          "type": "string", 
          "defaultValue": "root" 
        }, 
        "password": { 
          "type": "password", 
          "exportName": "password" 
        }, 
        "destinationFileName": { 
          "type": "string", 
          "defaultValue": "foo.txt" 
        }, 
        "workingDirectory": { 
          "type": "string", 
          "defaultValue": "/tmp" 
        }, 
        "ip": { 
          "type": "string", 
          "exportName": "target" 
        } 
      }, 
      "outBindings": { 
        "out_result": { 
          "name": "result", 
          "type": "string" 
        } 
      } 
    } 
  }, 
  "outputs": { 
    "out_result": { 
      "type": "string" 
    } 
  }, 

  … 
}

vRO_CUSTOM

The purpose of the vRealize Orchestrator (vRO) custom workflow tools is to run any vRO workflow in a Telco Cloud Automation (TCA) workflow. The custom workflow has only one mandatory input binding called vroWorkflowName. This input binding defines the name of the custom workflow to be executed. Additional input bindings may be specified to provide input for the workflow execution in vRO.

The following is a sample code snippet for workflow execution in vRO.

{
  "name": "testCustomVro",
  "version": "v1",
  "schemaVersion": "3.0",
  "readOnly": false,
  "startStepId": "stepId1",
  "inputs": {
    "vimInput": {
      "type": "vimLocation",
      "required": true
    }
  },
  "steps": {
    "stepId1": {
      "type": "VRO_CUSTOM",
      "inBindings": {
        "vim": {
          "type": "vimLocation",
          "exportName": "vimInput"
        },
        "vroWorkflowName": {
          "type": "string",
          "defaultValue": "REPLACE_NAME"
        },
        "vro_in_string": {
          "type": "string",
          "defaultValue": "in1"
        },
        "vro_in_integer": {
          "type": "number",
          "defaultValue": 123
        },
        "vro_in_double": {
          "type": "number",
          "defaultValue": 123.4
        },
        "vro_in_boolean": {
          "type": "string",
          "defaultValue": true
        },
        "vro_in_file": {
          "type": "file",
          "defaultValue": "fileInWorkflow.bin"
        }
      },
      "outBindings": {
        "out_string": {
          "name": "vro_out_string",
          "type": "string"
        },
        "out_integer": {
          "name": "vro_out_integer",
          "type": "number"
        },
        "out_double": {
          "name": "vro_out_double",
          "type": "number"
        },
        "out_boolean": {
          "name": "vro_out_boolean",
          "type": "boolean"
        },
        "out_file": {
          "name": "vro_out_file",
          "type": "string"
        }
      }
    }
  },
  "outputs": {
    "out_string": {
      "type": "string"
    },
    "out_integer": {
      "type": "number"
    },
    "out_double": {
      "type": "number"
    },
    "out_boolean": {
      "type": "boolean"
    },
    "out_file": {
      "type": "string"
    }
  }
}

Note: The vRO custom step allows you to use a vRO workflow in a TCA workflow. However, the workflow used must exist in vRO.

vRO_EXEC

VRO_EXEC allows you to execute scripts on virtual machines without having SSH. You must fulfill the following prerequisites before implementing the step through vRO:

VM tools should be present in the virtual machine.
vRO should be integrated with vCenter as the workflow that resides in vRO interacts with the vCenter API.

If these prerequisites are fulfilled, you can execute the step on virtual machines in vCenter or vCD.

The step has the following input bindings.


Name	Type	Mandatory	Note
`username`	string	Yes	The username to log in to the virtual machine.
`password`	string with password format	Yes	The password to log in to the virtual machine.
`vduName`	virtualMachine	Yes	The name of the VDU.
`script`	string	Yes	The script to execute.
`scriptType`	string	Yes	The type of the script.
`scriptTimeout`	string	Yes	The maximal time (in seconds) to wait for the script to complete.
`scriptRefreshTime`	string	Yes	The period in seconds at which the script execution is checked.
`scriptWorkingDirectory`	string	Yes	The working directory from which the script is executed.
`interactiveSession`	boolean	Yes	An interactive terminal.

To integrate the vCenter instance in vRO:

Log in to the VMware Telco Cloud Automation.
Click Inventory > Workflows.
Expand the workflow for which you want to view the vRO instances.
In the workflow steps, click below Action.
Click Open Session to log in to the vRO orchestration client automatically.
Click View Instance.
This navigates you to the execution.
In Orchestrator, click Library > Workflows.
Click on the right side of the workflow beside the filter box.
Click Library > vCenter > Configuration > Add a vCenter Server Instance.
Click Run.
In the Set the vCenter Server instance properties tab, enter the IP / FQDN of vCenter as it is registered in TCA-CP without HTTPS.
Note: Leave the port, SDK URL, and ignore certificate fields as default. Alternatively, for newer versions, ensure that ignore certificate is selected.
In the Set the connection properties tab, deselect the first option and enter the vCenter administrator credentials.
In the Additional Endpoints tab, retain the default values and click Run.
This integrates the vCenter instance in vRO. You must verify that it is successful.

To verify if the vCenter instance is successfully integrated with vRO:

In Orchestrator, click Administration > Inventory.
Click vSphere vCenter Plugin.
From the list of vSphere vCenter Plugins, click the vSphere vCenter Plugin with the IP / FQDN that you provided for vRO integration with vCenter and verify if your vCenter is listed, and you can browse the inventory.
Note: If your vCenter is listed and you can browse the inventory, it indicates that your vCenter instance is successfully integrated with vRO. If the integration fails, see vRO documentation for detailed information on vRO integration with vCenter.

VRO_EXEC does not require connectivity between vRO and the virtual machine but requires connectivity from vRO to vCenter. The vRO workflow that implements the step is called Run Script In Guest and can be inspected by logging in to vRO. The step has the following input values:

{
  "inputs": {
    "target": {
      "type": "string",
      "required": true
    },
    "password": {
      "type": "string",
      "format": "password",
      "required": true
    }
  },
  "steps": {
    "stepId1": {
      "type": "VRO_EXEC",
      "inBindings": {
        "username": {
          "type": "string",
          "defaultValue": "root"
        },
        "password": {
          "type": "password",
          "exportName": "password"
        },
        "vduName": {
          "type": "virtualMachine",
          "defaultValue": "myVduName"
        },
        "scriptType": {
          "type": "string",
          "defaultValue": "bash"
        },
        "script": {
          "type": "string",
          "defaultValue": "uptime"
        },
        "scriptTimeout": {
          "type": "number",
          "defaultValue": 12
        },
        "scriptRefreshTime": {
          "type": "number",
          "defaultValue": 3
        },
        "scriptWorkingDirectory": {
          "type": "string",
          "defaultValue": "/bin"
        },
        "interactiveSession": {
          "type": "boolean",
          "defaultValue": false
        }
      },
      "outBindings": {
        "out_result": {
          "name": "result",
          "type": "string"
        }
      }
    }
  },
  "outputs": {
    "out_result": {
      "type": "string"
    }
  }
}

JavaScript

The JavaScript (JS) step input is used to process workflow inputs or variables. The JS step has one mandatory input binding that specifies the script to be executed. This input binding consists of string type and text format. The text format allows you to enter multiline strings as values. The JS input can have any number of additional input bindings that allow the values to be passed through the script for processing. The output bindings specify how the results of the script execution are interpreted.

Input binding

The following is a sample code snippet for script input binding:

{ 
  "inputs": { 
   "input1" : { ... } 
  }, 
  "variables": { 
   "variable1" : { ... }, 
   "variable2" : { ... } 
  }, 
  "steps": { 
    "stepId1": { 
      "type": "JS", 
      "inBindings": { 
        "script": { 
          "type": "string", 
          "format": "text", 
          "defaultValue": "…" 
        }, 
        "myJsInput1": { 
          "type": "number", 
          "exportName": "input1" 
        }, 
        "myJsInput2": { 
          "type": "number", 
          "exportName": "variable1" 
        } 
      }, 
      "outBindings": { 
        "jsOutput1": { 
          "name": "variable1", 
          "type": "number" 
        } 
    } 
  },  
  ... 
}

The script input binding contains the JavaScript to be executed. This script contains a plain JavaScript code, and only those features of JavaScript required for data manipulation are used. Therefore, you cannot access the external resource line HTTP connections or files. At the time of executing JavaScript, the engine searches for the function with the following signature:

function tcaMainV1(workflowExecutionId, stepExecutionId, inputs, variables, startTime){ … }

The engine executes the function and populates the input parameters of the function with the following values:

workflowExecutionId: Workflow execution identifier.
stepExecutionId: Step execution identifier.
inputs: Mapping of input binding values.
variables: Mapping of the variables.
startTime: The timestamp (EPOCS) at which the step execution started.

The dictionary structure contains the following fields:

Aborted: A Boolean value if the step execution aborts.
Output: the output values of the step where the key to the map is the name of the value and the value is the computed value.

Logs: An array of log messages that belong to the step execution. A log entry contains the following mandatory fields:

msg: The log message.
Time: The time of the log message

Level: The level of the log message that contains one of the following values:

ERROR
INFO
DEBUG

function tcaMainV1(workflowExecutionId, stepExecutionId, inputs, variables, startTime) { 
    return { 
        "aborted": false, 
        "output": { 
            " jsOutput1": (inputs.myJsInput1 + inputs. myJsInput2) / 2, 
        }, 
        "logs": [ 
            { 
                "msg": "msg1", 
                "level": "DEBUG", 
                "time": startTime + 1000 
            }, 
            { 
                "msg": "msg2", 
                "level": "INFO", 
                "time": startTime + 2000 
            } 
        ], 
    } 
}

K8S

The purpose of the K8S action is to interact with the Kubernetes API securely. The K8S action makes it possible to execute scripts in a POD. These scripts can have UNIX commands such as awk, bash, jq, nc, and sed or commands that interact with the Kubernetes API such as kubectl and helm. The commands that interact with the Kubernetes API are prepopulated with the Kubernetes environment, and they work without credentials.

The system automatically allows access to the API to apply the principle of least privilege. This provides the service account with access only to the relevant network function or VIM.

Note: The helm version used during CNF LCM operations may differ from the helm version available during the execution of the K8S step.

The scope of the step is defined by the following access rights:

NF_RO: Read-only access to the network function on which the workflow is executed. Read-only indicates that only REST requests that require get, watch, and list Kubernetes verbs are allowed, and only the resources that belong to the network function are visible.
Note: The associated resources depend on the configuration mode of the policy service.
NF_RW: Read-write access to the network function on which the workflow is executed. Only the resources that are associated with the network function are visible.
Note: The associated resources depend on the configuration mode of the policy service.
VIM_RO: Read-only access to every resource on the Kubernetes cluster in which the network function is hosted or to the VIM, which is selected by the vimLocation input binding of the step. Read-only indicates that only REST requests that require get, watch, and list Kubernetes verbs are allowed.
VIM_RW: Unrestricted access to every resource on the Kubernetes cluster in which the network function is hosted or to the VIM, which is selected by the vimLocation input binding of the step.

From the RBAC perspective, the user who initiated the workflow has sufficient privileges to use the resource with the selected privilege level (read-only/read-write).

You can specify the cluster in which you have created the POD via the target input binding. The target can have the following values:

WORKLOAD: The POD starts on the same cluster as the network function or VIM selected by the vimLocation optional input binding. The workload cluster provides a good distribution of the used resources as the POD always consumes resources from the network function or selected VIM.
MANAGEMENT: The POD starts on the management cluster that manages the VIM of the network function or the selected VIM. The management clusters should only be used if the workload cluster has no free capacity to run additional temporary PODs since this solution is not fully scalable as it is limited by the resources of the workload cluster. Even if the POD is running on the management cluster, it cannot access the management cluster but can access the workload cluster.

Optionally, you can specify a node selector to further constrain the location of the PODs. In this case, you can specify the nodeSelector input binding that sets the kubernetes.io/hostname: <value> specified as the POD node selector.

Besides these fixed input bindings, you can specify any additional input binding. These additional input bindings are available as environment variables or files during the step execution.

The following table shows the input bindings.


Name	Type	Mandatory	Note
`script`	string	Yes	The script to execute.
`target`	string	Yes	The location of the POD. WORKLOAD MANAGEMENT
`scope`	string	Yes	The scope of the execution. NF_RO NF_RW VIM_RO VIM_RW
`nodeSelector`	string	No	The location constraint of the POD.
`any`	any (cannot be a file)	No	The input required for the script.
`any`	file	No	The file required for the script.

The runtime environment of the POD where you execute the script has the following properties.

Available binaries: awk, bash, jq, head, helm, kubectl, nc, sed, tail.
Each additional input is available as an environment variable. The name of the environment variable is the TCA_INPUT_ concatenated with the name of the input binding. For a file, the location of the file is specified as a value.
The CNF environment variable is set with the identifier of the network function if the step is executed within the context of a network function.
The network service environment variable contains the name of the network function if the step is executed within the context of a network function.
TCA_NAMESPACES environment variable contains the comma-separated list of namespaces where the network function resides if the step is executed within the context of a network function.
CLUSTER_NAME environment variable contains the name of the workload cluster if the script is executed within the WORKLOAD target.

The following sample code snippet provides an example workflow template fragment for this step.

{
  "inputs": {
    "script": {
      "type": "string",
      "format" : "text",
      "required": true
    },
    "target": {
      "type": "string",
      "required": true
    },
    "scope": {
      "type": "string",
      "required": true
    },
    "nodeSelector": {
      "type": "string",
      "required": false
    }
  },
  "outputs" : {
    "FINAL_OUTPUT" : {
      "type" : "string",
      "description" : "Final Output"
    }
  },
  "steps" : {
    "step0" : {
      "type" : "K8S",
      "inBindings" : {
        "timeout": {
          "type": "number",
          "defaultValue" : 60
        },
        "script" : {
          "type" : "string",
          "format" : "text",
          "exportName" : "script"
        },
        "inputNumber" : {
          "type" : "number",
          "defaultValue" : 22
        },
        "target" : {
          "type" : "string",
          "exportName" : "target"
        },
        "scope" : {
          "type" : "string",
          "exportName" : "scope"
        },
        "nodeSelector": {
          "type" : "string",
          "exportName" : "nodeSelector"
        },
        "file1": {
          "type": "file",
          "defaultValue" : "file1.txt"
        },
        "file2": {
          "type": "file",
          "defaultValue" : "file2.txt"
        }
      },
      "outBindings" : {
        "FINAL_OUTPUT" : {
          "name" : "result",
          "type" : "string"
        }
      }
    }
  },
  …
}

The following sample code snippet has a workflow template fragment for running Kubernetes workflows on a VIM without a network function context.

{
  "inputs" : {
    "script": {
      "type": "string",
      "format" : "text",
      "required": true
    },
    "target": {
      "type": "string",
      "required": true
    },
    "scope": {
      "type": "string",
      "required": true
    },
    "vimId": {
      "type": "vimLocation",
      "required": true
    }
  },
  "outputs" : {
    "FINAL_OUTPUT" : {
      "type" : "string",
      "description" : "Final Output"
    }
  },
  "steps" : {
    "step0" : {
      "type" : "K8S",
      "inBindings" : {
        "script" : {
          "type" : "string",
          "exportName" : "script",
          "format" : "text"
        },
        "inputNumber" : {
          "type" : "number",
          "defaultValue" : 22
        },
        "target" : {
          "type" : "string",
          "exportName" : "target"
        },
        "scope" : {
          "type" : "string",
          "exportName" : "scope"
        },
        "myVimId": {
          "type": "vimLocation",
          "exportName" : "vimId"
        },
        "file1": {
          "type": "file",
          "defaultValue" : "file1.txt"
        },
        "file2": {
          "type": "file",
          "defaultValue" : "file2.txt"
        }
      },
      "outBindings" : {
        "FINAL_OUTPUT" : {
          "name" : "result",
          "type" : "string"
        }
      }
    }
  },
  …
}

API Netconf

The purpose of the Netconf step is to interact with a service that has a Netconf interface. Network elements provide a Netconf interface as a configuration interface. It is used to set or retrieve configuration data from a Netconf-capable device.

The following table shows the input bindings.


Name	Type	Mandatory	Note
`action`	string	Yes	The type of action. `get`: Request the committed configuration and device state information from the NETCONF server. `getconfig`: Request configuration data from the NETCONF server. The child tag elements <source> and <filter> specify the source and scope of data to display. `merge`: The device merges new configuration data into the existing configuration data. `replace`: The device replaces existing configuration data with the new configuration data
`username`	string	Yes	The username to authenticate
`password`	string with password format	Yes	The password to authenticate.
`hostname`	string	Yes	The IP or DNS name of the service.
`port`	number	Yes	The port number of the service.
`inFile`	file	Yes, if config is empty and the action is "merge" or "replace".	The configuration file used.
`config`	string	Yes, if inFile is empty and the action is "merge" or "replace".	The content of the configuration.

The following workflow template fragment illustrates the usage of the netconf step.

{
  "inputs": {
    "hostname": {
      "type": "string"
    },
    "password": {
      "type": "string",
      "format": "password"
    }
  },
  "steps": {
    "stepId1": {
      "nextStepId": "stepId2",
      "type": "NETCONF",
      "inBindings": {
        "action": {
          "type": "string",
          "defaultValue": "merge"
        },
        "inFile": {
          "type": "file",
          "defaultValue": "netconf.content.1.xml"
        },
        "username": {
          "type": "string",
          "defaultValue": "admin"
        },
        "password": {
          "type": "string",
          "format": "password",
          "exportName": "password"
        },
        "hostname": {
          "type": "string",
          "exportName": "hostname"
        },
        "port": {
          "type": "number",
          "defaultValue": "17830"
        }
      },
      "outBindings": {
        "out_step1": {
          "name": "result",
          "type": "string"
        }
      }
    },
    "stepId2": {
      "nextStepId": "stepId3",
      "type": "NETCONF",
      "inBindings": {
        "vim": {
          "type": "vimLocation",
          "exportName": "inVim"
        },
        "action": {
          "type": "string",
          "defaultValue": "replace"
        },
        "inFile": {
          "type": "file",
          "defaultValue": "netconf.content.2.xml"
        },
        "username": {
          "type": "string",
          "defaultValue": "admin"
        },
        "password": {
          "type": "string",
          "format": "password",
          "exportName": "password"
        },
        "hostname": {
          "type": "string",
          "exportName": "hostname"
        },
        "port": {
          "type": "number",
          "defaultValue": "17830"
        }
      },
      "outBindings": {
        "out_step2": {
          "name": "result",
          "type": "string"
        }
      }
    },
    "stepId3": {
      "nextStepId": "stepId4",
      "type": "NETCONF",
      "inBindings": {
        "vim": {
          "type": "vimLocation",
          "exportName": "inVim"
        },
        "action": {
          "type": "string",
          "defaultValue": "get"
        },
        "username": {
          "type": "string",
          "defaultValue": "admin"
        },
        "password": {
          "type": "string",
          "format": "password",
          "exportName": "password"
        },
        "hostname": {
          "type": "string",
          "exportName": "hostname"
        },
        "port": {
          "type": "number",
          "defaultValue": "17830"
        }
      },
      "outBindings": {
        "out_step3": {
          "name": "result",
          "type": "string"
        }
      }
    },
    "stepId4": {
      "type": "NETCONF",
      "inBindings": {
        "vim": {
          "type": "vimLocation",
          "exportName": "inVim"
        },
        "action": {
          "type": "string",
          "defaultValue": "getconfig"
        },
        "username": {
          "type": "string",
          "defaultValue": "admin"
        },
        "password": {
          "type": "string",
          "format": "password",
          "exportName": "password"
        },
        "hostname": {
          "type": "string",
          "exportName": "hostname"
        },
        "port": {
          "type": "number",
          "defaultValue": "17830"
        }
      },
      "outBindings": {
        "out_step4": {
          "name": "result",
          "type": "string"
        }
      }
    }
  },
  "outputs": {
    "out_step1": {
      "type": "string"
    },
    "out_step2": {
      "type": "string"
    },
    "out_step3": {
      "type": "string"
    },
    "out_step4": {
      "type": "string"
    }
  },
  …
}

TCA_SSH

You can use the TCA SSH to execute the SSH commands on external entities, such as NFs and routers. The SSH connection from the TCP perspective originates from TCA-CP instanceto the target. Connectivity is established between TCA-CP and the external system.

The following table lists the TCA SSH step input values.


Name	Type	Mandatory	Note
`cmd`	string	Yes	Script to be executed.
`hostNameOrIP`	string	Yes	IP address or DNS name of the target system.
`username`	string	Yes	Username to be used.
`password`	string with password format	Yes	Password to be used.
`port`	number	No defaults to 22	TCP port of the SSH service.
`passwordAuthentication`	boolean	No defaults to true
`encoding`	string	No defaults to utf-8	Terminal encoding to be used.

If the script to be executed is very long, you can use the TCA SCP action to transfer the script to be executed to the target.

The usage of the SSH step is illustrated with the following template fragment:

{
    "name": "TCA_SSH",
    "version": "1.0",
    "startStepId": "step0",
    "schemaVersion": "3.0",
    "readOnly": false,
    "inputs": {
        "HOSTNAME": {
            "type": "string",
            "description": "Hostname",
            "defaultValue": "10.176.160.11",
            "required": false
        },
        "USER": {
            "type": "string",
            "description": "Username",
            "defaultValue": "admin",
            "required": false
        },
        "PWD": {
            "type": "password",
            "description": "Password",
            "defaultValue": "dm13YXJl",
            "required": false
        }
    },
    "outputs": {
        "FINAL_OUTPUT": {
            "type": "string",
            "description": "Final Output"
        }
    },
    "variables": {},
    "hierarchy": [],
    "tags": [],
    "steps": {
        "step0": {
            "type": "TCA_SSH",
            "description": "new Step",
            "conditions": [],
            "inBindings": {
                "password": {
                    "type": "password",
                    "exportName": "PWD"
                },
                "port": {
                    "type": "number",
                    "defaultValue": 22
                },
                "passwordAuthentication": {
                    "type": "boolean",
                    "defaultValue": true
                },
                "cmd": {
                    "type": "string",
                    "defaultValue": "uptime"
                },
                "encoding": {
                    "type": "string",
                    "defaultValue": " "
                },
                "hostNameOrIP": {
                    "type": "string",
                    "exportName": "HOSTNAME"
                },
                "username": {
                    "type": "string",
                    "exportName": "USER"
                }
            },
            "outBindings": {
                "FINAL_OUTPUT": {
                    "name": "result",
                    "type": "string"
                }
            }
        }
    },
    "id": "94f4ab85-211a-441d-b67b-2b6b30de8021"
}

TCA_SCP

You can use the TCA SCP workflow to transfer the file to external systems, such as NF and router, using the SCP protocol. The TCA SCP workflow is executed using TCA-CP. The SSH connection from the TCP perspective originates from the TCA-CP instance to the target.

The following table lists the step and the corresponding input values.


Name	Type	Mandatory	Note
`inFile`	file	Yes	Name of the attachment to be transferred.
`destinationFileName`	string	No defaults to the name of the attachment	Name of the file to which the file is copied.
`workingDirectory`	string	Yes	The path where the file is copied.
`ip`	string	Yes	The IP or DNS name of the target system.
`username`	string	Yes	Username to be used.
`password`	string with pasword format	Yes	Password to be used.

The following workflow template fragment illustrates the usage of the TCA SCP step:

{
    "name": "TCA_CopyFile",
    "version": "1.0",
    "startStepId": "step0",
    "schemaVersion": "3.0",
    "readOnly": false,
    "inputs": {
        "HOSTNAME": {
            "type": "string",
            "description": "Hostname",
            "required": false
        },
        "USER": {
            "type": "string",
            "description": "Username",
            "required": false
        },
        "PWD": {
            "type": "password",
            "description": "Password",
            "required": false
        },
        "inFile": {
            "type": "file",
            "required": false
        }
    },
    "outputs": {
        "FINAL_OUTPUT": {
            "type": "string",
            "description": "Final Output"
        }
    },
    "variables": {},
    "hierarchy": [],
    "tags": [],
    "steps": {
        "step0": {
            "type": "TCA_SCP",
            "description": "new Step",
            "conditions": [],
            "inBindings": {
                "password": {
                    "type": "password",
                    "exportName": "PWD"
                },
                "destinationFileName": {
                    "type": "string",
                    "defaultValue": "destination"
                },
                "workingDirectory": {
                    "type": "string",
                    "defaultValue": "/tmp"
                },
                "ip": {
                    "type": "string",
                    "exportName": "HOSTNAME"
                },
                "inFile": {
                    "type": "file",
                    "exportName": "inFile"
                },
                "username": {
                    "type": "string",
                    "exportName": "USER"
                }
            },
            "outBindings": {
                "FINAL_OUTPUT": {
                    "name": "result",
                    "type": "string"
                }
            }
        }
    },
    "id": "7cea2ae1-8c5a-4ed2-ac0b-89f8ce3ec4ce"
}

TCA_EXEC

TCA_EXEC allows you to execute scripts on virtual machines without having SSH. You must fulfill the following prerequisites before implementing the step through TCA-CP:

VM tools should be present in the virtual machine.

If these prerequisites are fulfilled, you can execute the step on virtual machines in vCenter or vCD.

The step has the following input bindings:


Name	Type	Mandatory	Note
`username`	string	Yes	The username to log in to the virtual machine.
`password`	string with password format	Yes	The password to log in to the virtual machine.
`vduName`	virtualMachine	Yes	The name of the VDU.
`script`	string	Yes	The script to execute.
`scriptType`	string	Yes	The type of the script.
`scriptTimeout`	string	Yes	The maximal time (in seconds) to wait for the script to complete.
`scriptRefreshTime`	string	Yes	The period in seconds at which the script execution is checked.
`scriptWorkingDirectory`	string	Yes	The working directory from which the script is executed.
`interactiveSession`	boolean	Yes	An interactive terminal.

The step has the following input values:

{
    "name": "TCA_VMTools",
    "version": "1.0",
    "startStepId": "step0",
    "schemaVersion": "3.0",
    "readOnly": false,
    "inputs": {
        "USER": {
            "type": "string",
            "description": "Username",
            "defaultValue": "root",
            "required": false
        },
        "PWD": {
            "type": "password",
            "description": "Password",
            "defaultValue": "Y2EkaGMwdw==",
            "required": false
        }
    },
    "outputs": {
        "FINAL_OUTPUT": {
            "type": "string",
            "description": "Final Output"
        }
    },
    "variables": {},
    "hierarchy": [],
    "tags": [],
    "steps": {
        "step0": {
            "type": "TCA_EXEC",
            "description": "new Step",
            "conditions": [],
            "inBindings": {
                "scriptTimeout": {
                    "type": "number",
                    "defaultValue": 12
                },
                "interactiveSession": {
                    "type": "boolean",
                    "defaultValue": false
                },
                "scriptWorkingDirectory": {
                    "type": "string",
                    "defaultValue": "/bin"
                },
                "password": {
                    "type": "password",
                    "exportName": "PWD"
                },
                "scriptRefreshTime": {
                    "type": "number",
                    "defaultValue": 5
                },
                "scriptType": {
                    "type": "string",
                    "defaultValue": "bash"
                },
                "vduName": {
                    "type": "virtualMachine",
                    "defaultValue": "vdu1"
                },
                "script": {
                    "type": "string",
                    "defaultValue": "uptime"
                },
                "username": {
                    "type": "string",
                    "exportName": "USER"
                }
            },
            "outBindings": {
                "FINAL_OUTPUT": {
                    "name": "result",
                    "type": "string"
                }
            }
        }
    },
    "id": "2c7ec43f-d632-42da-a510-9c10effeee5f"
}