The last two posts have shown some interesting possibilities regarding integration between VMware’s vCenter Orchestrator (vCO) and NetApp Workflow Automation (WFA), however both methods were rather cumbersome. Having to write 100+ lines of javascript in a vCO scriptable task is not exactly convenient!
Fortunately, NetApp has published a vCO package which abstracts all of that code into a handful of workflows and actions easily consumed by vCO workflows. To execute a WFA workflow from vCO you only need to know the name of the WFA workflow and the inputs needed.
The package is available from the NetApp Communities here. Once you have downloaded the package, installation is easy, simply import it into your vCO instance using the GUI. You will need to do a bit of configuration (adding the WFA host name and credentials), but that’s it. Jack has a couple of posts that do an excellent job of describing the setup process on his blog.
The package includes a number of support workflows to do things like connect to the WFA server, check on the status of jobs, etc., which you can browse at your convenience. However, the workflow we are primarily interested in is the one titled “NetApp WFA Workflow Execution”.
This workflow accepts just two inputs, one is an array of the inputs, the other is the workflow name. Keep in mind that the input names provided here must match exactly the names used by the WFA workflow. To determine the inputs for a WFA workflow, use the vCO workflow “Get WFA Workflow Inputs”. This workflow accepts only one input, the name of the workflow, and during execution shows the input names, type, and if applicable, valid values for each of the WFA workflow inputs in the log after execution. A critical piece of information is also returned, which is whether the input is mandatory or optional.
So, now that we’ve explored the vCO workflow used to execute WFA workflows, how do we use it? Well, we are going to create a wrapper workflow in vCO…
Step 1: Determine inputs needed, and valid values where appropriate
Using the above “Get WFA Workflow Inputs” workflow, we need to determine all of our inputs, their types, if they are mandatory, and valid values. Execute the workflow then copy->paste the output into a text editor for later reference.
Here is what the log looks like after the workflow has been executed:
For this example I am using the “Create a Clustered Data ONTAP Volume” WFA workflow. It has the following inputs, and properties associated with them, as reported by the vCO workflow used to determine inputs:
[2014-07-09 14:38:13.725] [I] User Input #1 [2014-07-09 14:38:13.726] [I] Name=ClusterName [2014-07-09 14:38:13.726] [I] Type=Query [2014-07-09 14:38:13.726] [I] AllowedValues [2014-07-09 14:38:13.727] [I] Value=cluster1 [2014-07-09 14:38:13.727] [I] Mandatory=true [2014-07-09 14:38:13.727] [I] ---------- [2014-07-09 14:38:13.727] [I] User Input #2 [2014-07-09 14:38:13.728] [I] Name=VserverName [2014-07-09 14:38:13.728] [I] DefaultValue= [2014-07-09 14:38:13.728] [I] Type=Query [2014-07-09 14:38:13.729] [I] Mandatory=true [2014-07-09 14:38:13.729] [I] ---------- [2014-07-09 14:38:13.729] [I] User Input #3 [2014-07-09 14:38:13.729] [I] Name=VolumeName [2014-07-09 14:38:13.730] [I] Type=String [2014-07-09 14:38:13.730] [I] Mandatory=true [2014-07-09 14:38:13.730] [I] ---------- [2014-07-09 14:38:13.730] [I] User Input #4 [2014-07-09 14:38:13.731] [I] Name=VolumeSizeInGB [2014-07-09 14:38:13.731] [I] DefaultValue= [2014-07-09 14:38:13.731] [I] Type=Number [2014-07-09 14:38:13.732] [I] Mandatory=true [2014-07-09 14:38:13.732] [I] ----------
There are four inputs for the WFA workflow, all of which are mandatory. Two of them (the ClusterName and VserverName) have a type of “Query”. What this means is that when the workflow is executed from the WFA interface a SQL query is being executed in-order to populate the values. We can, for now, treat these as string type inputs.
Step 2: Create a new workflow, configure attributes and inputs
Create a new vCO workflow in the standard way. Once it’s created we want to create a string attribute for holding the name of the WFA workflow. In a bold statement of cleverness, I have named this attribute wfaWorkflowName. The value will be Name Of the Workflow, Case Sensitive! (for the example, I’m using Create a Clustered Data ONTAP Volume). Additionally, we will need an attribute to store the inputs in their formatted state between steps later in the vCO workflow, so add that one as well…I have cleverly named this one wfaInputs, it should be an Array type.
After adding the attributes, move to the inputs tab of the vCO workflow and create an input for each of the mandatory WFA inputs. The vCO inputs must have the same (case sensitive!) name as the WFA inputs! Additionally, ensure that you are setting the types correctly for the inputs. While this isn’t strictly necessary, it does make data input and data validation easier in the future.
Using the data collected in step 1, here is how my inputs look:
Step 3: Configure the Presentation for the vCO workflow
We want to pretty up the interface and make it flow in a cohesive manner. If you like the way that WFA requests the data, then you can mimic it’s inputs. If not, configure it how you like. The important part is to configure the properties for each of the inputs to set whether they are mandatory (or not), if they have valid values that need to be checked (using a regex for example), and/or if they have predefined values that you can provide.
In this example I don’t want the user to have to manually type in the cluster name or the SVM name, so I am creating those inputs with predefined values. This will create a drop-down selection box in the vCO workflow’s GUI. I also want to prevent them from requesting volume sizes that are completely out of line, so I have a maximum value for the VolumeSizeInGB set to 1024 (1TB).
There are some restrictions on volume names additionally (these are defined by Data ONTAP), so I want to check for those now to prevent an error later on. Those restrictions (as of clustered Data ONTAP 8.2) are that the name must start with a letter (capital or lowercase) and can not be more than 203 characters in length. To check for this I am using two input properties…a maximum length and a regular expression.
Step 4: Prepare the inputs for WFA
Change to the schema view of the vCO workflow. We want to add a new action element, drag and drop that item from the left side menu to the schema. When you release the mouse button a window will appear which asks for the action to include. We want to use the “generateNetAppWFA_Inputs” action. This action will take the vCO workflow inputs and put them into the format expected by the “NetApp WFA Workflow execution” workflow.
Once the action has been added we will want to edit it to set the output value. There are no inputs for this action, so we don’t need to worry about that, but we do need to take the result of the action and assign it to the attribute we created in step 2. You can do this from the “OUT” tab or from the “Visual Binding” tab, but the end result should be to assign the output of the action to the wfaInputs attribute.
Step 5: Add WFA workflow execution task
Between the above input preparation action object and the end-of-workflow object, drag-and-drop a new workflow object to the schema of your vCO workflow. In the ensuing window search for the “NetApp WFA Workflow execution” and select it. Once it’s added, click the pencil on the object to edit it.
We need to assign the two attributes to the appropriate workflow inputs, so change views to the inputs tab and make the assignments. Alternatively, use the visual binding tab to do the same thing.
And that’s it. You’re done. Go ahead and click the “Debug” button. You will get an error saying that validation resulted in some errors, however they should be non-critical (it doesn’t think the inputs are being used, and it doesn’t like that we aren’t doing anything with the output from the “NetApp WFA Workflow execution” workflow). Select your cluster and SVM values, give a volume name and size, then click submit.
In the background all of the parts and pieces will be done to execute the WFA workflow. Just like in our manual execution before, it will determine the UUID of the WFA workflow, but it takes a few additional steps, such as doing a test execution to check for valid inputs, and then a real execution of the workflow, including waiting for it to finish executing before returning (hopefully, successfully!).
In this example we are not checking for returned values from the WFA workflow, though you could do that if you need the values to be passed along to another step or another workflow.
This just scratches the surface of what is possible by integrating a simple WFA workflow into vCO. In the next post we will explore using the a connection to the WFA database from vCO to provide input values dynamically, just like WFA workflows executed natively do.
If you want to know more about WFA/vCO integration, if you have questions and/or suggestions about the WFA package for vCO, or if you encounter a bug in the package, please let me know via the comments section here, the NetApp Communities page, or using the NetApp Communities private message function (my username is asulliva). I will also happily respond to emails…my email address is the same as my Communities username at netapp.com.
Questions and comments are always welcome below. If you have any suggestions for, or need help with, NetApp/VMware integration, automation, and solutions, please let me know using the comments!
The post Using the NetApp OnCommand WFA package for vCO appeared first on The Practical Administrator.