Navigation
TAG: vCACCustomWorkflows

Creating & Running vCAC Workflows, in an “On” State

One of the things that I like about vCAC , is the ability to run workflows in each different stage of the machine provisioning. This enables us to do a lot of the manual work that usually occurs when a machine is requested in our organisation , automatically with vCAC workflows. In order to take advantage of the full vCAC workflow capabilities, we will need a CDK license for our vCAC instance. “CDK” is actually an acronym for “Cloud Development Kit”.

What the CDK actually does is allow us to upload new workflows to the database, using the cloudutil.exe utility, installed when we install it and the vCAC Designer. Also, it will install a Visual Studio plugin for us, allowing us to easily create new xaml files (Microsoft’s .Net Workflow file format) with all the stuff we need to run in vCAC. The installation is fairly simple (Just remember to put the vCAC Web Server FQDN name, and the 443 port ), so I’ll jump to the more important stuff.

Before we get started, I must say I know there are quite a bit of “how to create a custom workflow” posts, but I posted this with the intent of showing some interesting fact I found regarding an “On” state workflow specifically. Lets get started!

To create a new workflow, we will open Visual Studio (needs to be 2010/2012) and create a new project

The new project should be of a type C# workflow, as seen on the right pane, and I usually choose activity library, which is simply an empty workflow file.

vCAC WF Generator

Now, we will click the vCAC Workflow Generator from the tool menu. If you’re seeing it as greyed out, just click the Add-In Manager, uncheck the tool, and try to select it once more from the tool menu.

vCAC Workflow Generator

After that, we’ll see the workflow menu popping up. Here, we’ll click the two “Add” buttons, in order to generate a new workflow xaml file in our project, and also so we can add the necessary references from vCAC dll’s so we could use the vCAC CDK activities.

our second menu will require us to enter a workflow name, and type. Yes I named mine “AppDeployMonitoringAgent” as a hint to what will this workflow do. Generally, naming workflows with good names is a real best practice, as things get complicated once we run a lot of custom workflows. The workflow is a “StateChange” workflow, since it will activate once a machine’s state had been changed to an “On” state.

Also, I’ve put a good Custom Property name as indication that the workflow should run. “App.Deploy.MonitoringAgent”.

Next step is to grab the workflow files from the project’s folder, and do the following:

1. External-<Name of workflow>.xml

– Put this file in the vCAC Manager Server, at: <vCAC Install Directory>\Server\ExternalWorkflows\xmldb

Example: C:\Program files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb

Attention! –  In order to run an “On” state workflow, you need to edit the file , and replace the

[xml]<MasterWFStateCriteria>On<MasterWFStateCriteria>[/xml]

from “On” , to “^On$”. Why? Well, vCAC will catch the machine’s state with RegEx, so by catching the phrase “On” we’re actually running the workflow at “InitialpowerOn” and “TurningOn” states as well… This could lead to unwanted workflow results. The replaced value will make sure that the workflow will run only once the machine is up and running.

After replacing the value, and putting the file in the xmldb folder, you should restart the vCAC Manager Service.

2. <Name of Workflow>.xaml

– Grab the file from the project’s folder, and put it somwhere it would be easily accessible from command line.

– Open a command prompt and navigate to <vCAC install folder>\DesignCenter

– We will use the cloudutil.exe file (AKA “vCAC Designer”) to enter the command:

[powershell]cloudutil.exe workflow-install -f workflowfilename.xaml -n workflowname[/powershell]

A good install would look like this:

That’s it, you’ve now installed a new workflow in the vCAC Repository and can access it from the “Load” button in the designer. We can now edit the workflow to do whatever we want, usually it’s going to be some powershell activity in an “On” state. But, I’ve got even more interesting scenarios for this machine state than you think. Find out in my next post!

BTW, do not forget to add the custom property you gave your workflow in the desired blueprint.

Building vCAC Multi Machine Workflows

An important part of provisioning machines with vCAC is creating multi machine blueprints. As such, It is important to understand the flow of these kinds of blueprints when inside a custom workflow. With a regular workflow, things are pretty easy. The “virtualmachineid” parameter is passed into the workflow you are running at the moment (e.g workflow stubs, or any other custom workflows) and vualla everything is accessible with it, and the standard vCAC Designer actions will probably meet your needs.

When we’re running a workflow on a multi machine blueprint, things are a bit different, and some questions arise. Where does the workflow run? when? and how many times? how can I know which machines are inside the multi machine blueprint so I can interact with each separately during my workflow? Well, lets dive in and start answering some of these questions.

First of all lets get some must knowledge on MultiMachine blueprints / vCAC workflows:
– When you apply a custom property to a Multi Machine blueprint, it applies to all component virtual machines as well (Remember that when you apply a custom property or a stub that launches a workflow… yes, the workflow will run the number of N component VMs you have + 1 for the multi machine blueprint object)
– The mgmtContext parameter is in fact a link to the database  at the moment of the workflow. Use LINQ queries to interact with it and manipulate it.

So after this quick preview of things lets get to it.

The first thing you will want to do when running a multi machine workflow, is decide whither you want to run it from a master machine perspective, or for each machine separately. For this decision process we will use a simple “if” flow object. In order to determine what is exactly the machine type. We will start by getting the virtual machine object from the databaase, using a common LINQ query used in vCAC workflows:

[code]
/*This is a long line, please notice*/
mgmtContext.VirtualMachines.Expand(Function(v) v.VirtualMachineProperties).Where(Function(v) v.VirtualMachineID = VirtualMachineId).FirstOrDefault()

[/code]

This query will get us the current VM according to its ‘virtualmachineid’ which we get as a parameter into the workflow. The ‘MasterMachine’ variable is defined of type “DynamicOps.ManagementModel.VirtualMachine”  which is the object type definition for a VM in vCAC. Applying this LINQ query to the ‘MasterMachine’ variable is done with a simple ‘Assign’ workflow action:

Getting vCAC Machine Object

Now, with our Machine variable populated, we can check the following ‘If’ statement:

If Machine is Not a Component

This will essentially tell us whether the VirtualMachineId we’re working on is an actual VM in the MultiMachine BluePrint, or the “Master Machine” itself. meaning, the MultiMachine Blueprint Object itself.

Once we have the MultiMachine object, we can access all of it’s component VMs in a few more steps!

First, we will use a second LINQ query, to get a list of all Component Machines for our MultiMachine Blueprint.

[code]
mgmtContext.AppServiceComponents.Expand(Function(AppServiceComponents) AppServiceComponents.VirtualMachine.VirtualMachineProperties).Where(Function(v) v.AppServiceVirtualMachine.VirtualMachineID=VirtualMachineId).toList()
[/code]

We will create an ‘Assign’ workflow object to Assign this LINQ query to a variable we’ll create, with the name AllChildMachines, of type ‘System.Collections.GenericList’ This is a .Net type for a linked list. Each of the list’s component type should be ‘Dynamicops.ManagementModel.AppServiceComponent’

Gell All child Machines

AllChildMachines Variable Type

Next, we will need to create a ‘Foreach’ workflow object, that is also of type: ‘Dynamicops.ManagementModel.AppServiceComponent’. The Foreach loop will run on each of are associated vCAC VMs with the Master VM, and in at that part of the workflow, we will populate a VirtualMachine variable for that particular VM.

Foreach VM in Master Blueprint

The  LINQ Query used here, is similar to our first query, and is:

[code]
mgmtContext.VirtualMachines.Expand(Function(v) v.VirtualMachineProperties).Where(Function(v) v.VirtualMachineID = item.virtualmachine.virtualmachineid).FirstOrDefault()
[/code]

If your sharp, you’ll notice the logic change here, this time the LINQ Query is grabbing the virtual machine with the same ID as our current ‘item’ in the foreach loop, thus running on each and each VM.

If you’re using the regular vCAC Designer objects, such as “GetVirtualMachineName” you’ll use them like:

GetChildMachineName

From this point of the workflow you can run whatever you want on each ‘childmachine’. For example, apply a certain logic to look at all VMs , read properties, and decide what to do. Act upon each machine separately, or whatever else you might need to do. I recommend using the ‘Flowchart’ object for maximum flexibility (and not the sequence object shown here for easier reading purposes).

Don’t forget to set our last variable, “ChildMachine” of type ‘DynamicOps.ManagementModel.VirtualMachine’!

Enjoy, and leave your comments below!

There are no more results.