Workflow Concepts
Before rushing headlong into workflow modification, it is crucial to understand some of the key workflow concepts:
- User permissions
- Credentials
- Attributes
- Parameters
- Schema
- Tokens
- Locking
- Presentation
The following sections each cover one of these key concepts.
User Permissions
Orchestrator has the capacity to restrict access to workflows to a specific set of users or groups. The permissions you can set on a workflow are as follows:
- View: View elements of the workflow except schema and scripting
- Inspect: Same as View, with the addition of scripting and schema
- Execute: Run the workflow
- Edit: Edit the workflow
- Admin: Set permissions on the workflow
The workflow permissions flow from the permissions set on the folder that contains it if you do not set any permissions on the workflow. In other words, if you do not set permissions, they are inherited. When you do set permissions on a workflow, it overrides the permissions of the upper-level folder, even if that folder is more restrictive. In addition, it is important to note that these permissions are not cumulative. That is, a user assigned Admin also needs to be assigned Edit to be able to edit workflows, and all permissions require the View permission. To edit the permissions to a folder or workflow, do the following:
- Right-click the folder/workflow, and select Edit Access Rights.
- Choose Add Access Rights.
- In the chooser, specify the user and permissions.
- Save and close.
Credentials
Being a techie, when unwrapping Orchestrator and starting to write the volume you are now holding, I decided, “Who needs manuals” and started rolling, that is until this particular property of workflows and the SSH plug-in. If you skipped that section of Chapter 5, “vCenter Orchestrator Plug-Ins,” I’ll spare you some page flipping: “...the SSH plug-in will use the credentials of the logged-in user executing the workflow.”
Where this got me, is that vCO will use one of four ways to determine who the executing user is. These four ways are contained in Table 6.1.
Table 6.1 The Four Ways vCO Uses to Determine the Executing User
How Was the Workflow Started? |
The Credential vCO Will Use |
vCO web or GUI client |
The logged-in user’s credentials |
Via policy |
Credentials set up for the policy |
Nested workflow |
Can get credentials from parent |
Web view |
Credential of user logged in to web view |
If none of these suit you, vCO also allows you to set the credential to run the workflow using either the Schedule Workflow As or Run Workflow As menu item.
Attributes
For those who are familiar with some basic programming concepts, attributes are roughly analogous to global variables and constants for a workflow. For those without a programming background, it can be helpful to think of attributes as being a reference to a value that can be accessed from anywhere within a given workflow.
Take, for example, our “Email Logs” workflow in the next section. The attributes we defined for the workflow were zipFileName and emailAddress. We were then able to access and manipulate these values later in the workflow as we needed.
Parameters
In the context of workflows and vCO, parameters are essentially the values a workflow will accept as inputs or generate as outputs. In our “Email Logs” example in the next section, this is the localPath parameter, or the path where the workflow will store its output. This enables the user executing the workflow to specify the location, making the file easier to find later.
Schema
The schema! When editing workflows, you will spend most of your time either scripting or in the schema editor. The schema editor is a Visio-like workflow diagram builder. As you’ll see in Figure 6.7, the interface itself is straightforward and lets you link the various workflow objects into a flow chart.
Tokens
Workflow tokens are a depiction of the current state of a workflow’s execution. Table 6.2 shows these states and their meanings.
Table 6.2 Workflow Tokens
State |
What It Means |
Running |
Workflow is currently running. |
Waiting for user interaction |
Workflow is paused waiting on user-supplied input. |
Waiting for event or timer |
Workflow is paused waiting on either an external event or a timer to complete. |
Canceled |
Someone cancelled the workflow. |
Failed |
For one reason or another, the workflow failed to execute. |
Completed |
Well... you would hope they all got to this state. |
Locking
Locking is a feature that disables your ability to edit a workflow while it is running. The ability to edit a running workflow is useful while developing workflows and interactive troubleshooting of a workflow. However, after you have determined that the workflow itself is “golden” or ready for production, it is best to lock the workflow to prevent accidental editing and unexpected results. It is also useful to lock a workflow if you will have more than one person editing or developing the workflow.
Presentation
Another key concept to consider during workflow development is the workflow presentation. That is, vCO gives you a large degree of flexibility in how the user is prompted for information at workflow execution time that covers both the vCO Java client and the web views, if you have them published. Why is presentation important? Well, consider that it helps with workflow usability and to ensure that you end up with valid inputs from the user. Along these lines there are two key points for presentation: constraints and decorators.
In terms of presentation, constraints enable you to set default, minimum, and maximum values. Constraints ensure those using your workflows are kept within the defined limits of your system. For example, when a user kicks off a workflow to build a new VM, you can set a default value for the OS, set a minimum (and maximum) for the disk size, and place constraints on memory. This has the benefit of allowing the user some customization while preventing an accidental denial of service because a VM was configured too large or too small.
In addition, workflow presentation enables the use of decorators. Decorators enable you to organize items in the interface and to show or hide elements or provide custom validation. For example, if you only want user darmok.jalad@tanagra.com to log in, you can add a custom validation to check the username.