From the Rough Cut
From the Rough Cut
From the Rough Cut
Workflow Concepts
Before diving headlong into workflow modification, it is key to understand some of the key workflow concepts. These are as follows:
- User Permissions
- Credentials
- Attributes
- Parameters
- Schema
- Tokens
- Locking
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 & scripting
- Inspect – Same as View with the addition of scripting & 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. This way if you do not set permissions, they will be inherited. Additionally, it is important to note that these permissions are not cumulative. That is, a user assigned Admin will also need to be assigned Edit to be able to edit workflows. To edit the permissions to a folder or workflow, do the following:
- Right click folder/workflow, select “Edit Access Rights.”
- Choose “Add Access Rights.”
- In the chooser, specify the user & 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 sec-tion of Chapter 5, I’ll spare you some page flipping: “…the SSH plugin 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 exe-cuting 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 users credential |
| Via Policy | Credentials set up for the policy |
| Nested Workflow | Can get credentials from parent |
| Web view | Credential of user logged into 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 items.
Attributes
For those who are familiar with some basic programming concepts, attributes will be 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 where the “localPath” or path where the workflow will store it’s output. Allowing 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 script-ing, 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 straight forward, and let’s you link the various workflow objects into a flow chart.
Tokens
Workflow tokens are a graphical depiction of the current state of a workflow’s execu-tion. Table 6.2 shows these states and their respective icons:
Table 6.2 Workflow tokens
| State | Icon | 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. | |
| Cancelled | 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 interac-tive troubleshooting of a workflow. However, once 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.
Modifying the Built-In Workflows
“Development of the mind can be achieved only when the body has been disciplined. To accomplish this the ancients have taught us to imitate nature”
— Kahn, Kung Fu
Like imitating nature in Kung Fu, Workflow-Fu is also best learned by imitating the workflows that come built into vCO. We spend a good deal of time copying and modify-ing workflows in Part 3 of the book, however there is a basic process to editing workflows that to
In our example we will be modifying the “Export logs and application set-tings” workflow as shown in Figure 6.2 to send the resulting application logs via e-mail to a defined user.
)
Figure 6.2 “Export logs and application settings”
To do this, we will need to follow these steps:
- Duplicate the workflow
- Edit the workflow
- Edit schema
- Edit User Interaction
- Edit Script
- Validate workflow
Duplicate the workflow
To duplicate the workflow, right click the workflow from Figure 6.2 and select duplicate workflow. From there, choose a name and new location for this workflow as shown in Figures 6.3 and 6.4 respectively.
)
Figure 6.3 Duplicating the workflow
)
Figure 6.4 Selecting the workflow destination
Edit the workflow
To get into the workflow editor, right click the newly created workflow, then click edit. The resulting workflow editor is shown in Figure 6.5.
)
Figure 6.5 Workflow editor
Our first order of business is to edit the description to something that more closely reflects what our end result will be. Next up, we will need to add an input to allow e-mail to flow.
Edit Schema
New we need to edit the schema of the workflow to add our extra e-mail task. This will take a few steps:
- Add user input
- Add scriptable task
- Edit new elements
- Done
Figure 6.7 shows the schema editor. Our first order of business is to add the user input task. To do this, select the link between the workflow start and the “Export” task as shown in Figure 6.8. Next you will need to right click and select “Insert… User Interaction” as shown in Figure 6.9.
Next we add in a scriptable task to send the email. To do this select the link between “Export” and the workflow stop as shown in Figure 6.10. With the link se-lected, right click and select “Insert… Scripting Task” as shown in Figure 6.11. The resulting workflow is shown in Figure 6.12.
)
Figure 6.6 Adding In-puts
)
Figure 6.7 Schema Edi-tor
)
Figure 6.8 Link Se-lected
)
Figure 6.9 Insert User Interaction
)
Figure 6.10 Link Se-lected
)
Figure 6.11 Insert Scripting Task
)
Figure 6.12 Final Workflow
Edit the User Interaction
We need to edit the default input task to populate the “emailAddress” attribute that we will use in the scriptable task. To do this, select the “User Interaction”, once selected we will work across the bottom tabs starting with “Info” shown in figure 6.13:
)
Figure 6.13 User Interaction > Info Tab
The next tab that we’re interested in is “External Inputs”, in this tab you will want to press “Control + B” to open the “Chooser…” window. From there, select the “Create parameter or attribute” link to the right of the search box. The resulting window is in Figure 6.14:
)
Figure 6.14 emailAd-dress attribute bound to user interaction task
From there click “OK” and, save the workflow, and select the “Scriptable Task” task.
Edit the Scriptable Task
Now comes the fun part, adding the e-mail script. We have a few tasks to sort out be-fore we get into the meat of the script however. We’ll work our way left to right using the tabs in the bottom windowpane.
First we’ll rename the “Scriptable Task” to “Email logs” as shown in figure 6.15.
)
Figure 6.15 “Email Logs”
Next we add parameters to the task. We’ll add both “emailAddress” and “localPath” to the task, allowing us to get at both the file and the e-mail address. To do this, select the “In” tab and press “Control + B”, the results are shown in Figure 6.16:
)
Figure 6.16 emailAd-dress and localPath added to script task
Next up, we select “Scripting” and add the following script:
var message = new EmailMessage();
var content = "vCO Logs Attached";
message.toAddress = emailAddress;
message.subject = "vCO System Logs";
message.addMimePart(content,"text/html; charset=UTF-8");
message.addMimePart(localPath,"application/zip");
System.log( "sending mail to host: " + message.smtpHost + ":" + mes-sage.smtpPort + " with user:" + message.username
+ ", from:" + message.fromAddress + ", to:" + mes-sage.toAddress );
message.sendMessage();
Code to create and send email with vCO logs attached.
The code above creates an “EmailMessage” type scripting object, checks to see if other email server parameters have been provided, and finally builds the message using our attributes as specified earlier.
Figure 6.17 shows the e-mail message that results.
)
Figure 6.17 E-mail with vCO logs attached.