Author Archives: Burke Azbill

How Much Javascript Do I REALLY need to know for VCO?

I find vCenter Orchestrator to have an extensive library of workflows, actions, and plugins to do what I need.  However, sometimes I do have to use the customizable Scriptable Task element to customize the behavior of a vCenter Orchestrator workflow.  Thankfully, this is super easy to do as the Scriptable Task is a very powerful element that allows me a full range of programmatic manipulation using the simple, open language of javascript.

When I use the Scriptable Task 99% of the time what I need to do centers around if/then/else, loops, data structures (arrays, objects), common method calling (the System object, the Server object, and plugin objects) variable retrieval (vm.config.hardware.numCPU), and string transformation (character strip, match, substring, format, etc).  So what does that really look like?  In this example our vCloud Automation center needs to add a machine to AD as part of the post provisioning process.  The “ou” parameter is passed in to the vCO flow, and we will use the AD plugin to search for the AD:OrganizationalUnit object and assign that object to the “group” variable. The group variable gets bound as an “Attribute” in our workflow and then passed in to the “Create a computer…” workflow element in order to add the server to the specified OU.  But first we must do some basic error checking to determine if the group exists first.

This could be a 7-10 element flow if you used the flow control elements and the Active Directory Plug-In actions in a flow.

OR – we could just use a Scriptable Task, grab those input vars, and use the AD object from the AD plugin in javascript!

A little if/then/else error checking, and then pluck the first matching group off of the returned array – DONE!

WHEW* simple right?  😉

Also, some best practices around flow creation with Scriptable objects is that you are creating re-usable packages.  So each one should be a short block of about 20-30 lines, and you should try to rename them that describes what they do.  For example:

It’s easier to understand what this does:

Than this:

Laying out your flow with Scriptable Tasks first, renaming them, and then filling in the javascript afterwards might also help you plan your workflow and save you time in the long run.

If this post just scared you a little (and I completely understand if it did), you can read more on best practices at  Also, if you’re looking to refresh some of your javascript skills I recommend spending an hour on, which has a free, interactive javascript course you can take using your browser.  Remember to focus on the data structures and language elements I specified above.

Article by: Jennifer Galvin – Sr. Systems Engineer

Many ways to start vCenter Orchestrator workflows

I noticed a tweet recently by someone who was “surprised that vCenter Orchestrator has so few ways to trigger the starting of a workflow.” This came as a surprise, because there ARE many ways you can trigger our workflows. I’d like to take this opportunity to educate the community on just how many ways there really are…

vCenter Orchestrator provides the following base methods of triggering workflows:

  • vCenter Orchestrator Client
    • Scheduler
    • Policies
  • Web Interface
    • WebOperator Webview
    • Perspectives Plug-in
    • Custom Webview
    • Wavemaker
  • vCenter Orchestrator API
    • vCenter Orchestrator SOAP Web Service
    • vCenter Orchestrator REST Web Service

vCenter Orchestrator Client

The vCenter Orchestrator Client allows administrators and permitted groups to launch workflows manually on a local or remote vCenter Orchestrator server. The functionality of running remote workflows is greatly enhanced when using the Multi-Node plug-in. Use of the vCenter Orchestrator Client is most common during the design, test, and troubleshooting of workflows. Additionally, the client offers the following methods of automated workflow triggering:

  • Scheduler: provides the ability to schedule workflows to be running at user-defined intervals. Use-cases would include recurring maintenance tasks such as disconnecting media from all VMs prior to backup, deleting old snapshots, automatically creating snapshots, etc…
  • Policies: Allows plug-ins such as the SNMP, AMQP, and vCenter to trigger workflows based on defined criteria. Use-cases would include remediating systems based on SNMP traps that exceed defined thresholds, responding to vCloud Director blocking tasks that have been posted to an AMQP bus, and starting a workflow based on state Change or thresholds of vCenter objects.

Web Interface

Lightweight administration may be performed using vCenter Orchestrator’s built-in webview functionality. The system uses Tapestry and Dojo technologies.

  • Weboperator: The Weboperator that ships with the product gives administrators the ability to browse the entire workflow library, start and/or schedule workflows. It also allows them to:
    • Tasks: View, Suspend, Cancel, and Delete tasks (Scheduled workflows)
    • Workflows: Start/Schedule, view schema, variables, and events, respond to workflows waiting for input
    • Policies: Start/Stop/Reset and view defined Parameters
  • Perspectives: The Perspectives fling allows an administrator to define a set of workflows to be accessible to an LDAP Group. For example, one could define 5 administrative/maintenance workflows to be visible to the Backup Admins group. Upon logging into the web interface, these Backup Admins would be able to start workflows, schedule them, view workflow execution events, schemas, etc…
  • Custom webview: Custom webviews are created by developers to present specific workflows in custom layouts not afforded by the auto-generated layouts presented by the Weboperator and Perspectives. Service providers have used this method for public offerings, providing “Cloud” services years before “Cloud” was the big keyword.
  • Wavemaker: There have been numerous blog posts on creating web interfaces for vCenter Orchestrator using this free product.


vCenter Orchestrator has always had a SOAP API available for interacting with it from remote systems. As of version 5.x, it also now has a more powerful REST API. The first visible use of the REST API is the vSphere Web Client. When properly configured, one can launch any number of workflows directly from the vSphere Web Client. Other VMware products that incorporate the ability to launch workflows include vSphere Service Manager and vCloud Automation Center. 3rd parties have also built in support to their products so that vCenter Orchestrator workflows may be launched.

Using either of these APIs, any number of scripting and/or programming languages are capable of triggering vCenter Orchestrator workflows. Examples may be found on blogs as well as in the VMware Communities.   A quick search on google reveals examples of using PowerShell, PERL, Python, PHP, C#, JAVA, .NET, and Ruby to interact with a vCenter Orchestrator server.

As we can see above, there are many different methods of triggering vCenter Orchestrator workflows. Providing standard APIs around SOAP and REST greatly increases ones ability to incorporate vCenter Orchestrator into existing systems.

How to deal with long running external processes

When building vCenter Orchestrator Workflows, chances are that you eventually have to integrate external systems with longer running (multiple minutes, hours, maybe even days) processes.

Examples for that are:

  • Software Deployment processes
  • Clone tasks
  • When you have to rely on processes that only occur once a day (like an automatic discovery in a monitoring system)
  • “semi-automatic” processes: The workflow creates a ticket, that is going to be processed manually, and continues with the automation after the ticket is closed.

 While it’s quite easy to initiate/trigger the external system to start that long running task, it is more challenging to programmatically figure out when the external task completed (and the continue with the workflow).
vCenter Orchestrator External systemsThis article shows different strategies to wait for long running external tasks and their advantages and drawbacks.

“Synchronous” processing:

Here the workflow in vCenter Orchestrator triggers a long running process in an external system, and when this process finishes, the external system actively “tells” vCenter Orchestrator that it’s done.
vCenter Orchestrator Synchronous processing This can be achieved through two (and a half) different ways:

  1. The external system is integrated via a Plugin that provides Trigger elements or Events for vCenter Orchestrator Policies.
    If that is the case, you can use a “Waiting event” element in the workflow while waiting for the external task to complete.
    Example: The “Wait for Task” Workflow in the vCloud Director Plugin does exactly this. It is used by all the workflows of the vCloud Director Plugin that trigger long running tasks in vCloud Director.
    vCenter Orchestrator plugin waitinga “and a half”) If there is no special Plugin for the system you call out to, but this external system “speaks” AMQP or SNMP, you can use these plugins. The AMQP Plugin provides a Workflow “Wait for a message” for this for example.
  2. Use a “User Interaction” element, that is answered by the external system via vCenter Orchestrator’s SOAP or REST API.

The workflow stops at the “User interaction” element, and waits for the answer.

Here the external system of course needs the ability to somehow call the vCenter Orchestrator API to answer the user interaction.

This way has a nice side effect: If something goes wrong in the external process, a human administrator can fix it and easily answer the element manually.

Having the external system actively call back to vCenter Orchestrator doesn’t waste any time when the external process is done. And it is not necessary for the workflow itself to examine that process (as it will be necessary with the next strategy).

“Asynchronous” polling:

If the external system which runs the long running process can not actively call back to vCenter Orchestrator, then there is only one other way to examine when it is finished: Polling.
vCenter Orchestrator asynchronous pollingTo allow a polling in general, a workflow in vCenter Orchestrator must be able to figure out that the external process has finished. This sometimes can be done by checking the external system directly, e.g. because its API allows to monitor these processes, or you can check for a certain state of the external system.

In case it is not possible to check the external system directly if the process has finished (because it only provides a “fire-and-forget” sort of API for instance), then you might use some “helper”: Check if a certain file exists in a specified place, or if there is a certain entry in a database (remember the SQL Plugin for vCenter Orchestrator!), or even if there just is a new email in the mailbox

When you made sure how the workflow can figure out that the external process is completed, the next challenge is to organize to schedule the polling. Here again there are different strategies possible:

  1. A loop in a JavaScript element that uses System.sleep()While this is a simple solution for short running processes, it is not recommended for to monitor longer running processes: System.sleep() keeps the workflow in a running state. So it keeps using system resources on the vCenter Orchestrator server.Example: The widely used “vim3waitTaskEnd”-Action in the vCenter Library that monitors the (usually short running) tasks in vCenter which have been triggered by vCenter Orchestrator.
    To save resources (and to not risk reaching the maximum number of concurrent running workflows, 300 in vCenter Orchestrator 5.1), it’s better to have the polling workflow in a not “running” state while waiting for the next poll. This can be achieved using following strategies:
  2. Use a “Waiting Timer” element
    You first calculate the date & time when the workflow shall continue (with the next polling iteration), and then use a “Waiting timer” element. This will let the workflow get into a “waiting” state, so it’s state gets persisted in the vCenter Orchestrator database, and it does not use any runtime resources (“waiting” workflows also don’t count to the maximum number of running workflows!). When the calculated time is reached, vCenter Orchestrator will automatically “re-awake” the workflow again.
    vCenter Orchestrator use Waiting Timer
  3. Use the Workflow scheduler
    vCenter Orchestrator allows to schedule workflows to run automatically at a given date/time, optionally with a recurrence, e.g. for every hour. Now you even can schedule workflows programmatically, using the “Schedule workflow” element in the schema. This can be used nicely for the polling workflows, it is even possible that the polling workflow schedules itself for the next run.Find an example how to do this (in a slightly other scenario, but you’ll can transfer it easily) in the communities:

However, all these strategies generate a linear growing: For every external process started one workflow waiting/monitoring/polling this process is generated. If you now have a lot of these, and/or very long running processes, then you might want to avoid this growing. Even that is possible with vCenter Orchestrator, by using Configuration Elements in a creative way. (In case you need a short “refresh” about Configuration Elements, read this article:

The idea is that a workflow starts a new external process, stores information about this process to a Configuration Element and then just finishes. Another SINGLE polling workflow then reads this Configuration Element, checks all external processes, and in case some of them finished it calls workflow that follows the external process.

So it does not matter if 5 or 500 external processes have to be monitored, there is always only one polling workflow active.

You can see, vCenter Orchestrator provides a lot of mechanisms you can use to build reliable workflow solutions even for difficult integration situations.

Article Author: Joerg Lew

No Code Workflow Reconnects ESXi Hosts

This example shows that one can do useful things without writing JavaScript code in vCO.
Ever since the vSphere 5 upgrade, cold booting my home lab (which I generally do because I’m not going to pay to leave it running all the time plus it is noisy and it heats up my office) requires re-connecting my ESXi hosts. 

I was tempted to write a Perl script or use PowerCLI but given my focus on vCO and with the new the vSphere 5 plugin, I thought, “I’ll write a workflow!”
So I started by looking at what was there and thinking it would be cool to do this in vCO without writing any JavaScript.
I easily found the delivered workflows for “Disconnect host” and “Reconnect host”.  


Trying those one at a time on one of my ESXi hosts and they worked perfectly.  Great.  These are my first building blocks.
Next I thought, “Ok, now I will sequence these two flows.”  No biggie.  I created a new workflow called “Disconnect Reconnect ESX Host”.  In the schema, I dragged a workflow item, select “Disconnect host” and repeated for “Reconnect host”.  Add the “End Workflow” item then link together.  


Next I clicked “Validate” and took the quick fix option to create an input attribute for “ESX host” which both embedded workflows can now share.  




I tried the flow on one of my ESXi hosts.  It worked great.  Cool.
So then I said, “Now I need to loop through all my ESX hosts in my lab cluster.”  Hmm, I remember Burke Azbill has shown me how to do this multiple times. J  And after a quick search I found it (again):
But I’m thinking that looks like too much work and I’m lazy.  Besides, I would rather fall back on my bad habits and just write a “foreach” loop in JavaScript and call the workflow in the script.  Not very “orchestrator-like” but I’m more of a “Perl” guy.  I resisted the temptation.
“Well, maybe I can just use what is there in vCO and not write something.  (I am so lazy.)  Hey, what about that Batch thing.  Yeah, baby.”


Since I had just added a new workflow that takes a single ESX host as input which qualifies to run from the batch workflow, I ran the “Fill batch configuration element”. Now I will be able to reference my “Disconnect Reconnect ESX host” workflow.

Now I want to verify that I can run my new workflow from the “Run a workflow on a selection of objects”.  I chose ESX host as the object type, selected the Action “GetallHostSystemsofCluster”, using my cluster for the input and then chose my “Disconnect Reconnect ESX Host” workflow.  


Outstanding, it cycled through my ESXi hosts disconnecting and then reconnecting each one very quickly.
Lines of code written: ZERO.
But you know I am really, really lazy.  How can I run this batch workflow without having to go through and configure all the inputs each time?  It was time for another workflow.  I remember Christophe Decanini telling me this could be done.
Ok time for one more workflow to setup and call the batch workflow the way I want for this job.  I called it “Disconnect Reconnect All ESX hosts of Cluster”.  Add one workflow item which is the “Run a workflow on a selection of objects”, add the “End Workflow” item and link it together.

Next I used a trick that Christophe Decanini taught me.  “Synchronize presentation” shows when you right-click on the embedded workflow.


This adds all the attributes of the embedded workflow as inputs to the current workflow.  While this is pretty cool, remember that I want to run this without any inputs at all.  Ok, there is a quick fix for this.  Move all the inputs as attributes.  Click on the top input, then Shift-Click on the bottom input.  When all the inputs are selected, right-click and choose “Move as attribute”.


Now the visual binding looks like this:


This is a complex workflow but I only need a few of the parameters.

Now all that is left is to set the defaults that I want for my lab to run this specific job.  This was actually pretty easy by looking back at the successful run of the batch flow previously and observing the variables that were actually used and their values.  


The objectType is a string and the value needs to be “Host”.  Not exactly intuitive but there it was in the variables from my previous run.  I used the same Action “GetallHostSystemsofCluster” as before and selected my cluster for the input to the Action and finally chose my “Disconnect Reconnect ESX Host” workflow.


“Look Mom, no parameters for input!”  And it worked fantastic.  No loop code in JavaScript or multiple vCO scriptable tasks, decision items, etc…  Dirt simple really.

This is good enough for me but if I am going to share this with others, I don’t want the workflow referring to the cluster in my lab.  So the one last improvement is to use a Configuration instead to reference the cluster to use.  This way you can set the Configuration to reference your cluster.  Create a new folder and element for the Configuration.


Then edit the Configuration and add an element setting the Type to VC:ClusterComputeResource. I called it “MyCluster” and set the default value to point to “Cluster1” in my lab.  Yes, this is quite the outstanding name, don’t you think?


Finally, I went back to the workflow and updated the “cluster” attribute default value to reference the configuration element.  Click the little symbol in the Configuration column.


Now pick the “MyCluster” Configuration element.


Finally, I created of Package of my work and saved it out for safe keeping.


Bill Call
Central Region US Principal Systems Engineer
Solution Specialist vCloud/Chargeback

Bill has been at VMware a relatively long time (8+ years) and has worked with various automation tools over 25+ years in IT.