Each workflow can have variables in three different areas. Variables are called attributes or parameters depending on where they are.

In JavaScript, the naming convention for variables is to start with lowercase and use uppercase when a new word starts, for example, myFirstAttribute, currentVM, and so on. This is what programmers call a camelCase convention. We should use the same convention when programming in Orchestrator.

Variables in the general section

A variable in the General section is called an attribute. An attribute is accessible throughout the whole workflow, but, not outside it. An attribute can have an initial value (at the start of a workflow), but it can also be changed at any stage.

Attributes are mostly used for two things: as a constant (defined once and not changing) or as a way to exchange a value between two workflow elements. You can lock an attribute (see the following screenshot) to make sure that the initial value can't be changed.

You can move an attribute to become an input or output parameter if you have created it in the wrong spot. Just right-click on the variable and choose the Move as... option:

Variables in the input section

A variable in the input section is called an in-parameter. The content of an input variable is defined at runtime and entered by the user. Input variables cannot be changed during workflow execution directly, as you cannot assign an in-parameter as the output of a workflow element. You can move an input parameter to become an attribute:

Variables in the output section

A variable in the output section is called an out-parameter. The content of an output variable can be defined within the workflow and is available to other elements when the workflow has finished. You can move an output parameter to become an attribute:

Variable types

There are many variable types that are already implemented in Orchestrator out-of-the-box, but the basic variable types are as follows:

Variable type	Description
Any	This can contain any content. It is used to carry variables to other elements that are not defined in the Orchestrator GUI, such as XML. Note that Any should only be used if nothing else will do, as it has been known to mishandle some content such as complex variables.
boolean	This has only two values, either true or false. However, Orchestrator uses Yes and No in the GUI.
Credential	This contains a username and password. The password is encrypted.
Date	This is used to store the date or time in the JavaScript format.
number	This contains only numbers, which can be integers or real numbers. Everything is stored as floats in Orchestrator.
SecureString	When entering values, *s will be shown instead of characters. The value is plain text and visible to the workflow developer, but encrypted when the workflow runtime information is stored in the database.
EncryptedString	This is like secure string; however, the value is always encrypted.
string	This can contain any characters.
NULL	This is not really a type, but defining a variable as NULL means that anything that is put into it will be discarded.

In addition to the base types, each plugin will install its own type. These types are identified by their prefixes. For example, types that come with the vCenter plugin have the VC: prefix and types from the SSH plugin have the SSH: prefix:

Any Orchestrator workflow programming is done in the schema; each element in the schema is connected by either a blue (normal), green (True), or dotted red (Error/False) line between a start point and an endpoint. You can have more than one endpoint, but only one start point:

Dropping an element on a line will insert it into the flow. You can delete elements or lines by right-clicking on them and selecting Delete (you can also use the Delete key).

To create a new line, hover the mouse above an element (see Scriptable task in the previous figure) and then drag one of the arrows to the destination element.

You can rename any element by just double-clicking on it and entering a new name.

In presentation, we define how the workflow input masks look and behave. You can define the order of the input fields, a default value, whether a given field should be mandatory and link it to other fields and values.

The presentation is quite handy for workflow execution used with the Orchestrator Client and the vSphere Web Client. For websites, and especially for workflows used in vRA, it's not that important. vRA itself has an interface that determines all the things above. See more about workflow presentations in vRA in the recipe Workflow presentation in Chapter 5, Visual Programming.