Hi again buddies! Let’s continue with vRO post series.
vRO deployment is really simple, just like other OVA deployments. You can find it well documented by VMware, check the version you are going to deploy because the procedure has changed in latest versions.
Assuming you have already deployed your vRO, now it is time to understand the philosophy of vRO Workflows.
Once you have logged in to Orchestrator Client, change to “Design”, and select the first tab “Workflows”.
Add a folder to place your test Workflows.
Then create your first Workflow inside.
One important thing, every time you save your workflow it will ask to increase version history or continue (We will see more on that later).
For this post I’ve created a Workflow called “Initiation Workflow”, it is a very simple Workflow, it will not help to automatize nothing of our environment, the goal is to understand vRO Workflows structure.
The Workflow accepts a number, makes a countdown until zero, and adds five to the provided number. Everything is logged so we can see the countdown and the result of adding five to the number.
Editing the Workflow, first we can see the “General” tab:
From up to down we can see the name of the Workflow, the ID (useful for remote commands) and version, I think this versioning is very important and I recommend using it to keep track of the changes made to the Workflow. Versioning is normally arranged with this order, first digit for major release, second for minor release and third one for bug fixes.
We can add a custom icon to our Workflow, add an owner and a signature, set up the Server restart behavior, the Resume from failed behavior and a Description, this last one I believe is very important too.
The last thing on “General” tab, is the section “Attributes”, Workflow elements process data that they receive as input parameters, and set the resulting data as workflow attributes or output parameters. Read-only workflow attributes act as global constants for a workflow. Writable attributes act as a workflow’s global variables. You can use attributes to transfer data between the elements of a workflow.
On the second tab we have “Inputs”, here we find the values that the Workflow will expect as input. We can define as many as needed, different types (number, string, Boolean, vCenter Objects and so on). They can be arrays, and also have composite types.
Next tab “Outputs” is like previous one but for the Workflow output values.
We will analyze “Schema” later, let’s see now “Presentation”. Here we define the presentation that Workflow consumers will see to input expected data.
We have created one section (Section 1), that will request our input variable “number”.
On “General” tab we placed the text “Number to make countdown” that will be the text shown before the box to input the number when we execute the Workflow.
We have set up some properties for the input variable, we added the property “Mandatory input” so the end user of the Workflow will not be able to submit the execution if value is null.
In addition, we added and fixed a maximum value to 100.
If we execute the Workflow from GUI, we can see that we cannot submit the execution without the “in” parameter.
We cannot give a value higher than 100, as requested in the properties of the presentation.
“Parameters References” shows up a summary of all defined variables, input, output and attribute.
“Workflow Tokens” gives us a view of executions and final state.
We find on “Events”, guess what? 🙂 , Workflow events.
The last one “Permission”, here we can limit who can run the Workflow.
Ok, now we have described all the tabs, but remember that we left “Schema” for later, we will see that and more… Stay tuned for Part 2.
Thanks for sharing 🙂