Using the vCO-to-WFA database connection

Previously we connected vCenter Orchestrator (vCO) to the NetApp Workflow Automation (WFA) database in order to perform queries against it. By itself this isn’t terribly useful when we are wanting to provide dynamically populated information to vCO workflows that are executing WFA workflows using REST.

The crux of the problem we are trying to address is that when executing a WFA workflow via REST we are not able to pre-determine valid values for inputs like the cluster or storage virtual machine names. The administrator(s) can provide static values, but this is only helpful with a subset of inputs (how frequently do you add a new cluster?). For volumes, which have the potential to be added and removed frequently this would become a burdensome task quickly.

One answer (there are others, which I will post about in the future) is to use the database. When a WFA workflow is executed natively (i.e. from WFA) it uses query based fields to determine those inputs. The data is populated by crafting SQL commands to pull the data form WFA’s cache database.

Workflow Automation Query Fields

Let’s take a look at one of those queries. Login to your WFA server in the standard way (http://your_wfa_host/wfa), then choose the “Designer” tab at the top. Choose a workflow…I have chosen to use the Create a Clustered Data ONTAP Volume workflow for this example. Right click the workflow and select edit. You should see a screen like this:

vca_wfa_action_1

In the top left corner select the “Setup” button, which will open up the Setup Details screen. Select the “User Inputs” tab, which will look similar to this:

vca_wfa_action_2

Notice how there are two inputs that have a type of “Query” and values of “evaluated at runtime”? Those are the inputs we are interested in. Double click one of them (I chose ClusterName) to open the variable editor screen.

vca_wfa_action_3

Near the middle is some blue text which reads “View or edit the SQL query executed at run time”. Click this text and a small text editor will open. What you see here is the SQL that is being executed in order to populate the values in that drop-down selector.

vca_wfa_action_4

The end result of this is that we now have the bit of SQL that we want to use when querying the WFA database from vCO to pre-populate the “Cluster Name” field with valid values.

Click the Cancel button three times, which will put is back at the main editor screen for the workflow. Now, in the lower right corner, click the “Preview” button. This will start the workflow and display the input screen. Click the drop down for “Cluster”…

vca_wfa_action_5

Notice how our SQL query above returned two fields, “Name” and “Primary Address”. Also notice how in the drop down of the GUI there are two columns with the same name? This is an interesting feature of WFA that allows us to provide some extra information to aid in making a selection. Unfortunately, the same feature is not available in vCO…but we don’t need to do anything about that yet, just keep it in mind for a bit.

vCenter Orchestrator Actions

I’m going to stray for just a moment to explain Actions in vCO. Actions can be thought of as analogous to functions in traditional programming. They are reusable bits of script which accept parameters and return values.

If you have already installed the NetApp WFA package for vCO, you can view some of the NetApp developed Actions by switching the mode of your vCO GUI to “Design”, then selecting the tab which has a gear with a blue triangle on it. Expand the folder named com.netapp.oncommand.wfa and you will see a number of the helper Actions for the package. Below is an example, this is the Action which we used in the previous post that takes vCO workflow inputs and puts them into the format that the “NetApp WFA Workflow execution” workflow expects.

vca_wfa_action_6

Actions can be called from workflows as elements in the schema, or from other actions and scriptable tasks programatically. Additionally, an action can be executed by a workflow to return values (or validate values, etc.) for inputs. This is the part that is important to us.

Our goal is to create an action which will query the WFA database and return an array of values that represent valid inputs for a particular field.

Creating a new Action

If you are looking at the Actions tab of the vCO GUI you will notice that there are a large number of folders holding Actions for a large number of operations. All (or at least many/most) of these are used by workflows to perform certain actions. We don’t want to pollute those modules, nor do we want to risk breaking anything, so let’s create a new module. At the root of the tree (the orange square with a circle), right click and select “New module”. The naming scheme is to use your companies domain name in reverse along with some descriptor. I have chosen to use com.practical-admin.wfa because these modules are created by me and relate to WFA.

vca_wfa_action_7

After hitting Ok a new, empty, folder will be created. Right click the folder and select “Add action”, which will prompt for the name. There is no convention here, I use something descriptive, but short. In this instance I have chosen “selectClusterName”. Once you click Ok the GUI will automatically open the new Action for editing.

vca_wfa_action_8

Defining Inputs and Outputs

The first step that we want to do with our new Action is define the inputs and outputs. Cluster Name is, usually, the first option chosen in WFA workflows, so there isn’t any input. If we were selecting a Storage Virtual Machine (SVM) name, then we would expect an input of “ClusterName” (with a string type), because we only want the SVMs for the cluster that the user has chosen. We can safely not specify any inputs for our sample Action.

We do however need to specify a return type. The default is void, which basically means the action doesn’t return any values. This is not what we want, so click the word “void” next to “Return type” in the upper left corner.

vca_wfa_action_9

The return value here should be an “Array of”, with the of being the same as the type of input in the workflow. I know it’s been a while, but remember back to the previous post where I said that a WFA “query” type should be treated as a string? So, we want to return an “Array of String” from our Action. In the upper left, select the radio button for “Array Of”, and in the lower section select “string”. Click “Accept”.

vca_wfa_action_10

The body of the Action

Ok. Take a deep breath. Let it out. Get a good, strong, drink. Ready? You’re sure?Ok, then…we’re going to write javascript. I know, I know! “But it’s sooooo scary!” “I’m not a programmer!” “I need my blankie!”

Don’t worry, it’s not that hard. Javascript is one of the easiest languages to use, and we aren’t doing too much of it here…I promise this will only hurt a little and we will all make it out alive.

We need to do three things in our javascript:

  1. Get the database connection
  2. Query the database
  3. Parse the result of the query and return the values

A quick note here: I am using vCenter Orchestrator 5.5.1 with SQL Plug-in 1.1.0. This is important because the API of the SQL Plug-in changed between 1.0.0 and 1.1.0, so please refer to the documentation if you have issues.

Here is the code that we need for our action:

50 lines of (heavily) commented javascript isn’t too bad (plus we could put some of the code, like section 1, into another Action since it is reusable across all of our database query actions).

One thing to note, notice how we are only returning the name of the cluster, not the name and the IP address. This is that difference that I made note of earlier. vCO does not have a convenience method of displaying multiple fields like WFA does. You could work around this by putting both values into a single string, however you would have to extract just the cluster name when sending the data to WFA for execution via REST.

Save and close the Action, we’re all done with it now.

Integrating the Action with workflow inputs

I’m going to assume that you have created the workflow from the previous post. If you haven’t, now would be a good time to do so.

Edit the workflow that was previously created (I titled mine “Create a Clustered Data ONTAP Volume”) and select the Presentation tab. Highlight the ClusterName input on the top pane, then in the bottom pane select the Properties tab.

We want to change the “Predefined answers” property from being an array of values to being populated by our action. To do this, we will change the value from from being statically defined (the drop down in the middle of the line with a strange box and a vertical bar on it) to being dynamically defined using OGNL (represented by the green double arrow).

vca_wfa_action_11

After making the change to OGNL, click the purple puzzle piece to the far right of the line which will open a dialog requesting the action to execute. In the filter type the name of the action we created (selectClusterName). Highlight our action, then press the Apply button.

vca_wfa_action_12

To test the action, switch back to the Schema view and click the debug button. If everything is working correctly you should see a list of all the clusters registered to WFA.

vca_wfa_action_13

If you get just a plain text input instead of a drop down, check the debug log for your workflow. It will tell you if any errors have occurred, and if the database query was successful, it will tell you how many records and the name of each cluster that should be in the drop down.

Conclusion

Using actions to dynamically populate workflow inputs with values begins to create a powerful and compelling use case. These dynamically queried values are further populated into vCenter Automation Center (vCAC) blueprints when the workflows are imported from vCO to vCAC.

This is only one part of enabling a services catalog that is fully integrated with your virtualization and storage environments. Further expanding these workflows, and making full use of vCAC, can enable your organization to begin creating a catalog of services which can be presented to the users via a self-service portal.

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!

3 thoughts on “Using the vCO-to-WFA database connection”

  1. Andrew,

    First this is great!

    Now for a question… 🙂

    I’m trying to use an external resource to populate a drop-down in a Service Blueprint.
    I have a table setup for the available environments eg: prod, dev, qa, uat, etc… it is a 2 field table.
    What I am expecting to be able to do is to use the 2 fields to populate the Label and Value for the drop-down, but I get no results. Do you have any idea how I would go about using an external source for the values in the drop-down or am I trying to do something not supported?

    Thanks
    Bill S.

    • Hello Bill,

      You will need to make sure you parse the output (WFA filter/finder, or direct SQL query) into an array of strings, which is the format that vRO is expecting for the drop down values. Also, note that it must be a single string…vRO does not interpret an object or hash and display additional information like WFA does.

      Hope that helps!

      Andrew

Leave a Reply