Integrate vCO


vCO integration with VMware View

Just that you do not miss it: @cloudnutz postet a great example how to leverage the Powershell plugin to call VMware View PowerCLI cmdlets from vCO Workflows:

Find the original post also on

And don’t miss some (unofficial, but don’t blame me (this time 😳 ) 😛 ) additional PowerCLI cmdlets for VMware View:

And Dear VMware View Team: Please give us a full (and documented) (and official) API!

Or even better: What about a View-Plugin for vCO?
I know a lot of customer having use-cases for it (and a lot of people having to use workarounds like this for now). Desktop-as-a-Service and Cloud Desktops need Orchestration (just to add the buzzwords for the robots 😈 )


Let your vCO Workflow text you! Yes, via SMS!

Working on another blogpost on some design best-practices for workflows (stay tuned…) a promising idea came into my mind:

What about sending text messages to my mobile from workflows?

I guessed there are many SMS-Gateway-Services out there which provide any kind of SOAP or REST-API… (I want to leverage an existing plugin for vCO for quick results). So google came up with this nice discussion:

I decided to give a try, because they

  • provide interational service
  • provide multiple kinds of API
  • seem to be reliable and widely used
  • don’t force you in a contract/monthly plan for my limited test usage

What you need to reproduce this example:

  • a clickatell account (I think it will work with most of the other SMS-Gateway services in a comparable fashion)
  • the REST-Plugin for vCO installed in your Orchestrator environment (see details here: (Select HTTP-REST for the plugin-download and a bunch of examples)


I quickly signed-up for an account, used the web-form to send a test message to German) mobile number, and prepaid for some credits to be able to send via the API.

After that, I created a new access for the “HTTP”-API of clickatell (no special settings):

(You may open clickatell’s API Documentation now in background if you’re a read-first-try-then kind of guy.)
For myself I just started my vCO client and ran the “Add a REST host”-Workflow from the library, providing just a name and as URL:

The workflow finished sucessfully, I confirmed the new host in the Inventory:

Now I called the “Add a REST operation”-Workflow to invoke the API-Call to clickatell (based on their example given when creating the API account):

(instead of hardcoding my credentials I used the generic {parameter}-notation of the REST-plugin for all the necessary parameters like username, password, API-Id, …, so that I can re-use the  operation later flexibly). The full “Template URL” value is:


When the operation was created (again: Confirm in Inventory-Tree) I started the “Invoke a REST operation” workflow providing all the input parameters:

aaand voila,  😎 seconds later the text messgae arrived on my mobile!   :mrgreen:

Now, the real-world use-case:

Well, sending generic messages to a mobile from a vCO workflow is cool|geeky, but what for? For a realistic example I used the Workflow-Generation of the REST-Plugin to let vCO generate my very own “Invoke ‘send a text message'”-Workflow in my very own Workflow folder for easy re-usage:

So I was able to re-use the created workflow in my Snapshot-Hunter-Workflow… (you know the pain with backup software which accidentally forgets to cleanup the VM snapshots! :evil:)

(The first element to find these workflows leverages the xpath-filter of the VcPlugin.getAllSnapshots()-Method, see the discussion here: and )

At the end: After scheduling the workflow as Scheduled Task in vCO, starting from tomorrow I will get waked-up by my mobile receiving an text message from vCO when there are leftover snapshots from the nightly backups!


  • Don’t fear any tasks integrating vCenter Orchestrator! When the external system provides an API, chances are that you get in run in a few minutes…
  • Remember: less and simple workflow inputs make it easy to use, many and generic workflow inputs make it easy to re-use! (referencing the “Workflow Development Best Practices”-session as a shameless plug :mrgreen:)
  • Sometimes it IS good to be creative|distracted when drafting a blog-post (expect the post I actually was working on soon…)
  • Turn off your mobile when you want to sleep in!
  • …and thank god I’m too tired to think about other use-cases for this…
    (I will not make an Orchestrator & Ringtone joke!
    I do not plan to provide a monthly subscription for my content, just text a SMS with “vCO Rockz!” to …..
    And I better not search for an API for Asterisk (“If you want to execute workflow XYZ, press 1; for all other requests press 2” 8-O)

Download the example

SnapshotHunter Package
SnapshotHunter Package
23.3 KiB

Be aware that it will NOT run out-of-the-box, because you have to add the REST-Host and the Operation in your environment! And: Don’t forget to set the necessary values for username, password, mobilenr, … in the configuration elements.You know that blogpost whith a great description of Configuration Elements, don’t you! 😛


How to find Inventory Objects when calling vCO Workflows via the SOAP API

When calling an Orchestrator workflow from outside via the SOAP-API, things get dirty if your workflow have input parameters (see details here: ). And things get really dirty, if the input parameter is an Inventory Object (like a Virtual Machine, provided by the vCenter Plugin).

The reason for that:
Before you can finally call the actual workflow, you have to get the vCO-internal ID of the object, usually by calling other API-methods before. In the vCO WebService documentation you can find following flow-chart, I marked the step we’re talking about:

Depending on what information the workflow caller has, you can call the findForId, or the find method with an xpath-expression. (expecially when working with the vCenter-plugin, always remember: The managed object Id in vCenter or the name of the Virtual Machine is not necessarily unique in vCO, because you always can have connections to multiple vCenter-Hosts!)

Thanks to David (@creativeview) and Igor a full example in Powershell:

$vcoWS = New-WebServiceProxy -Class VCO -Namespace VCO -Uri http://mycoolvcoappliance:8280/vmware-vmo-webcontrol/webservice?WSDL
#find the workflow
$workflows = $vcoWS.getWorkflowsWithName("Start virtual machine and wait", "vcoadmin" , "vcoadmin")
#find the virtual machine
$result = $vcoWS.find("VC:VirtualMachine", "xpath:name='TheVM-Name'", "vcoadmin" , "vcoadmin")
if ($result.TotalCount -gt 0)
$finderResult = $result.Elements[0]
$stringObjectRepresentation = $finderResult.DunesUri
#Write-Host $stringObjectRepresentation
$workflow = $workflows[0]
# print out input Parameters
# generate Array with Input PArameters (WorkflowTokenAttribute - Objects)
$inparams = @()
# fill the array, one entry for each input parameter
$inparams += New-Object -TypeName VCO.WorkflowTokenAttribute
$inparams[0].name = "VM"
$inparams[0].type = "VC:VirtualMachine"
$inparams[0].value = $stringObjectRepresentation
# Exectue workflow
$workflowToken = $vcoWS.executeWorkflow($, "vcoadmin" , "vcoadmin", $inparams)
(be careful with the ‘ and ” surrounding the xpath-expression, depending on which programming language you use)

See the full discussion in the forums (some Java lines included as well 🙂 ):

My original example how to call vCO Workflows via Powershell (with plain data types for input only :oops:):

You can also find some examples about this in the vco-examples-package, more information how to get started with this:

And an unofficial tip at the end: Rumors are that the next major release of vCO contains a new REST-based API, so don’t spend too much time learing this legacy stuff, if you don’t need to…


Using Wavemaker as Web-Frontend for vCO

UPDATE 23. Nov. 2011: Additional Reference: Christian Johannsen posted a great step-by-step example for Wavemaker & vCO on

There are different ways to create a web-based frontend for Orchestrator:

  • Webviews (included, provide integrated finder for inventory objects BUT old, hard to learn, deprecated, don’t bother to start with…)
  • Perspectives (based on webviews, very easy to use, way to go for quick-wins)
  • build your own (call Workflows via the SOAP-based API of Orchestrator)

(for more details, see this post)

Now, rumors are out there for a long time, it seems that Wavemaker is a hot candidate as main technology for the web-based stuff in future (it was mentioned at VMworld and in the forums… Yohooo!).

The Video

To get started, see following screencast…
Disclaimer: Starting at 6:30 it gets very dirty! Do not let your children nor your VMware Support Guy watch this unattended, and only try this at home! :mrgreen:

Wavemaker as Web-Frontend for VMware vCenter Orchestrator – Sneak Preview from Joerg Lew on Vimeo.

(I used the current 6.4.2 BETA of Wavemaker against vCO 4.1, but should work as well with slightly different versions of both components…)

So, why is Wavemaker a perfect fit (The GOOD…)?

It allows to to create nice-looking websites with a real bunch of logic without the need for tooooo much knowledge about web-development. (Orchestrator allows to create complex automation for your complete IT-Infrastructure without the need for tooooo much knowledge about software development)

It defines the information flow between different elements via a parameter binding semantic. (How do you pass information through a workflow in Orchestrator??)

You can drag&drop content elements from the palette to your actual website, and program additional logic in JavaScript (in the vCO you can drag&drop…. Well, you get the point…)

It uses the same platform. (see the dirty end of the video 😯 ), so a good integration is possible.

It’s the same company. (<EVILMODEON>So if VMware learned something from the  **yourAdjectiveHere** acquisition of Dunes some time ago, this time they get synergy earlier!!!<EVILMODEOFF>)

Drawbacks (The BAD…)

As external system, your wavemaker frontend has to call workflows via the API. So it is some effort to pass input parameters to the workflow, and it is a real bunch of effort (you don’t use “pain-in-the-ass” in a public blog :-?) if your workflow needs inventory objects as input.

So, in the current version you are bound to the features, the “usability”, and the limits of vCO’s current SOAP-API.

The Future (NOT ugly, quite the opposite!)

Two things on the horizon might make the Wavemaker<=>vCO-Integration perfect in future:
First, a new API in a future version of vCO could make the usage of inventory-objects as inputs easier;
Second, a bunch of pre-built vCO-related elements in the Wavemaker Palette could make the development of the web-frontend easier (compare it to the idea, not the complexity and not-documentation, of the vCO-related Tapestry objects in Webviews)….
=> Go vCO-Team! Go Wavemaker!


To get started with Wavemaker and the vCO-SOAP-API, see following links:


The way shown in the video using the SOAP-interface directly with a WebService-Variable in Wavemaker is not the only way (and maybe not the best one for every use-case). You can also create your own Java stubs (see the examples-zip in the Orchestrator Documentation), and use a “plain old” JavaService Variable against them in Wavemaker.


So in general, despite some hurdles due to the limits of the current SOAP-API, Wavemaker allows you to create good looking webinterfaces for Orchestrator Workflows. And it’s absolutely worth to dig into it, because this seems to be THE technology for webbased vCO-Access in the future.


Good read: Custom vs. Generic Plugins for vCO-Integration

Sergio (@sergiosagu) posted a great document in the Orchestrator Plugin SDK-section of the VMware Communities:

“Should I create a new Plugin for vCO…”

…or use one of the generic Plugins for REST or SOAP to create my integration?

It’s absolutely worth reading, even when you don’t plan to integrate with vCO (but “only” develop workflows for your environment), because a lot of points can be transfered to other integration challenges (like integrating databases) as well.

Page 6 of 8« First...45678