vCAC 6.0 is here, and things have changed drastically.

Now, it's up to us to leverage the power that comes with it, compliments of VMware!

So, this post will focus mostly on how to use the vCO workflow template so that we can do some cool stuff when Provisioning / Building / Expiring / Destroying a Virtual Machine.

In order to make the most of this particular post, please refer to my previous post "Running vCO Workflows from vCAC during the provisioning of a Virtual Machine".
The above post will help you understand how to configure vCO for use with vCAC, and configure your desired blueprints for integration with the vCO workflows.
In fact, this post assumes you have already done the above, or are familiar with it.

Right, down to business.
First off, a bit more about the lifecycle of a Virtual Machine.

Any Virtual Machine provisioned from within vCAC undergoes a lifecycle.
One is able to effectively "hook" into most of the states in the lifecycle to run a Workflow.
This is particularly useful when integrating with 3rd party systems such as Asset Management Systems and the like.

For the purpose of this post, let's assume we're doing just that.

The "Provisioned" and "Disposing" states are where will hook our custom vCO Workflows in to the lifecycle of the Virtual Machines.

The use case is, therefore, to create a record in an Asset Management System whenever a Virtual Machine is provisioned.

Side note: The difference between BuildingMachine and MachineProvisioned States is that in MachineProvisioned, the O/S is already laid down, and possibly undergoing customisations.
At BuildingMachine, the O/S has not been installed / configured yet.

By association, therefore, we will also need to delete / flag such records whenever a Virtual Machine is destroyed or has Expired.

So, let's first go ahead and look into creating a Workflow that calls out into an "Asset Management System".

Remote System Requirements

The first thing we need to understand is that Asset Management System "X" requires the following mandatory fields when creating a new Asset:

HostName
CPUs
RAM
Storage Space
Department

Furthermore, Asset Management System "X" accepts integration calls via SOAP Interface.

I have created a quick and dirty SOAP interface on my development machine that mimics Asset Management System "X".

Our vCO Workflows

We will need our Workflow to do a few things.

First, we will need to assimilate all the required properties from the Virtual Machine in context.

Thereafter, we will need to construct a SOAP message and send it to the system requiring integration.

Before we can achieve the above, we will need to configure a SOAP host within vCO by using the built-in SOAP Plugin in the vCAC 6.0 VA embedded version.

This can be found here:

For the purpose of this post, I'll just be configuring the IaaS Server as the SOAP Host, using the existing SOAP Service on the IaaS Server as a sample.

Also, it's worth noting that I did not add a proxy, and I also used no authentication against my service (in case you want to do the same).

The SOAP Method / Wrapper Workflow

Next, we need to generate a new workflow based on the invocation of a SOAP method:

Right, so once this is done, we would call this new workflow from another workflow that we are about to create.

To give you context on where we are, let's consider: We have just created the workflow that will call a Web Service (SOAP). This workflow / SOAP Service expects inputs.

According to my analysis above, the (Remote System Requirements) list includes 5 inputs that we will need to gather from a VM during the provisioning process (or, rather, just after the machine is provisioned).

Creating the Integration Workflow

This workflow will be created using the Template provided in the vCAC package below.
Simply, we will duplicate this template and use it as a foundation for our new workflow:

Once found, duplicate the workflow:

Give it a name and copy it somewhere to group your custom Workflows

Be sure to copy your custom workflows into a folder that can easily be exported without affecting anything else.

In the next step, below, if we edit the workflow we just created, one can see the vast list of inputs.

It's important to note at this stage, that there is no need to panic ;-)

All of these inputs are already 'automagically' supplied by the vCO integration engine.
All we have to do now is consume these inputs.

This means we instantly have access here, to information related to the Host, the vCAC VM Object, which stub called this instance, and also the Properties and additional Inputs.

Next, we'll go ahead and modify the workflow we've just created to gather information so that we can call the Web Service at Provisioning time.

Continue to Part 2