Latest Headlines

New Training available: VMware vCenter Orchestrator: Develop Workflows

UPDATE: To see the the currently scheduled classes, visit

VMware offers a brand-new training for Orchestrator users: VMware vCenter Orchestrator: Develop Workflows

The course is designed for people new to vCO, it starts with Install & Config, important Orchestrator Basics and the Workflow Development Methodology. After that the “real Orchestration-Power” is touched (at least a part of it, limited to the 3-day timeframe 🙂 ) by starting to integrate vCO with external systems.

Besides the theoretical part there is a lot of lab time (50-70%), with realistic tasks & workflows taken from real admin-life. The packaging chapter at the end allows you to export your work from the labs and take it home.

The training focuses on re-using existing building-blocks in vCO, however some basic scripting is involved. So the knowledge of any programming or scripting language is quite useful for the best training experience.

Also included is a chapter about the vSphere API its inventory structure, the data model and some useful tools. This may be interesting for any other vSphere automation (like PowerCLI) as well!

If you are want to book the training, ask your VMware Education Rep., your VMware Authorized Training Center (VATC) or me (I’ll bring you in contact with the proper people 😎 )

(Course Datasheet:


Problems with AD-Plugin for vCO? Uninstall all old Microsoft-Plugin-Stuff!

Some problems came up getting the ActiveDirectory-Plugin for Orchestrator run. Mostly the problems are related to wrong credential settings in the configuration:

If you had the (old) Micrsoft-Plugin installed, you have to uninstall it completely. For details about how to do this, and some explanation, follow this discussion on the forums:

The new AD-Plugin has no WMI-support. Powershell has a good WMI-support. So the PowerSShell-Plugin might fit into the gap? Surely worth to figure out more and draft some ideas for the Roadmap…;-)   Stay tuned!


vCenter Orchestrator 4.2 released… and mentioned in vCloud Architecture Toolkit (vCAT)

VMware just released vCO 4.2, included in the vCenter 5.0. Not a big release for the platform, but focussing on all the Orchestrator Plugins in the last couple of weeks indeed was more important 🙂 .Release notes state that the missing Schema-Chart in the Webviews are fixed!

And, whith the new AMQP-Plugin for vCO and the “Call-Out”-Feature of upcoming vCloud Director 1.5 it’s possible to execute Workflows during vCD-Operations. For more information about this, visit

Another sign for the rising importance of vCO: It is mentioned in the new vCloud Architecture Toolkit (vCAT) 2.0:

I’m looking to hear more at VMworld 2011 😎 !


Integrating vCO: Access a Database (Overview)

VMware Orchestrator allows you to access SQL-Databases from within workflows. This post shows you common Use-Cases for that, explain technical background and introduces three-and-a-half ways how to implement the database-access.


Accessing external databases within workflows is used to…

  • …integrate Your Workflows with external systems: You can retrieve or update information for an external system’s database (Ticket-System, Asset Management, CMDB, Documentation, Your VM-Deployment-System, ….
  • …build Your very own database-driven solution: If you create a larger “Suite” of workflows (like the VM-Deployment-System), expect that you have to deal with more and more metadata around the objects your workflows handle. A database is a good place to store this metadata, and it allows external systems to integrate easily with your Workflows in future.

Technical Background

The ability to integrate with external databases is presented by…. 😀

…the bundled  Database-Plugin. It provides a couple of Scripting-Objects for JDBC-Connections. So when you look for further reference information you can google for JDBC-Examples, they will fit (with some small limitations: Check the API Explorer of the vCO-Client to figure out the actual properties and methods of the JDBC-Objects).
In the bundled Workflow-Library you also find a Folder “JDBC Examples”, which provides a complete typical “lifecycle” of a database. Here you can also find a very useful Workflow called “JDBC Url Generator” which creates the correct complete JDBC-Connection-String you need to connect to the database.

Out-of-the-box, vCO supports Microsoft SQL-Server and Oracle-Databases, because for them the JDBC-Driver are pre-installed. However, it’s possible to add any other vendor’s JDBC-Driver; to get an idea, how to do this, see

Implementation Options

No matter, WHY you want to access external databases from your workflows, there are 3 (and a half) options to HOW do this:

1. Plain Database Access in Scripting Element

Just add a scripting element to your Workflow, and place the database operation in its JavaScript. This is useful, if you only call the database very rarely in defined workflows, and for single operations (For example: You want to update a documentation-database after deploying a new Virtual Machine).

2. Encapsulate Database Access to “DAO”-Actions

When you need database-calls more often in your workflows (Acutally, you should use this if you need it more than once :-)), you should encaplusate the database-calls into Actions. Typically you create pretty generic Actions for each CRUD-Operation, sometimes additional some “higher-level” Actions which do exactly the call you need often in the workflows.

(Side note: I call them DAO-Actions, compared to “Data-Access-Objects” in Software Engineering, when it comes to persistence and object-relational mapping in object-oriented software design.
Of course Actions are not “Objects”, but the idea is the same:)

So you create a single point/module, where all the database-related stuff is implemented. This makes it easier to do DRY-style developing, and rises the readability, re-useability, and maintain-ability of your works.
Consider the table-schema of the database you access is changing, so with DAO-Actions you only have to change the code in a single place.

Another big advantage using Actions to encasulate the database-access: You can use it in the Input Presentation of a Workflow! So you can get database-information even before the workflow starts. That can be used for example to make it easier for the end-user to start workflow which needs a VM as input, by providing a list of the current user’s VMs (and this information of course comes from the database):

.5 Call Stored Procedures

This is the “and-a-half” option, because it can be used in addition to the options above: JDBC allows you to call Stored Procedures of the database. This can be used e.g. if the vendor of an external system provide a bunch of Stored Procedures as an “API” for its database (or if you just want to pass all the SQL-work to the database-team :mrgreen: ).

See an example how to call a Stored Procedure in vCO.

3. Build Your own vCO-Plugin

The final option is the holy grail: Build Your own Plugin for the Orchestrator, which handles the integration to the external database. This of course is some effort, but it’s worth it if you integrate your workflows very frequently with this external database (or of course, if you build your own database-driven workflow-suite, see the second use-case above).

Building Your own custom Plugin allows you

  • to make database-entities accessible as JavaScript-Objects, and move all the database-specific stuff (table-layout, database connection details) to the Plugin. So the usage of the entities inside the Workflows and Actions is object-oriented, and all the SQL-stuff is hidden from the Workflow-Developer (see picture below).
  • to present database-entities as Inventory-Objects to the Orchestrator, which allows you to use these entities as Attributes and Input/Output-Parameters in Workflows. (Example: When integrating an Ticket-System, you can let the workflow-user select the actual Ticket for a certain workflow)

There are to flavors building such a Plugin:

1. Create the Plugin just with a vso.xml and some Hibernate-Mapping files (one for each entity you need in vCO). This allows you to present entites to the inventory, but you still have to wirte some generic JavaScript-Code in your Workflows & Actions.
On the other hand: You don’t need to develop a single line of Java-Code for the plugin 8-), and let the automatic Hibernate-Mapping-Feature of the Database-plugin do the work for you.

2. Create real Java-Objects in the Plugin and use the full vCO-Plugin API. This allows you to present your database-entities as real objects to the Workflows and Actions, and adds the full functionality of the API (like Triggers, …).
On the other hand: You have to develop Java-Code (a bunch of it), and you have to learn how the vCO-Plugin-API works. See the Solar-System-Plugin in the vco-examples-package an this presentation (Plugin-Development starts at ~28:45min) to get an idea of it. Good luck! 😈


The JDBC-Database-Plugin  provides very powerful integration-abilities for Your Workflows. You can start with a couple of JavaScript-lines for a simple integration, refactor them to DAO-Actions to have a clean Design when the need for integration grows, and unleash the full power of vCO by creating your own custom Plugin.


A WebService-Client for vCO: Running the samples

VMware vCenter Orchestrator provides a SOAP-based Web-Service API, which you can use to start and monitor workflows from an external System. (This can also be used to create a webbased Client for vCO with something else than Webviews, see a detailed discussion here)

For a quick-start VMware provides a fully-functional Java-based Example-Client in the In this post You will see how to build and run these examples.

You need:

  • A working Orchestrator Server
  • The Java Development Kit installed on Your Desktop
  • Ant
  • The, downloadable from the vCO-Documentation-Homepage


1. Download and install Ant (Don’t forget to set the environment variables JAVA_HOME, ANT_HOME and add the \bin-directories to your PATH!)

2. Download and unzip the vco-samples package.

3. Open a console, change to the webservice-example directory and run ant.

Use ant to build the examples

4. Edit the and insert the connection details to Your vCO-Server:

5. Now you can run the Inventory.bat to check if the Sample-client can access the vCO-Server as expected (You sould see an “Ascii-Art – Representation of Your vCO’s Inventory):

(If something goes wrong here, it might be hard to read the error-messages. Double-check your connection-settings (including correct username/password) in the!)

6. Most of the other samples in this Client access (hard-coded) Workflows. So you have to import the bundled Package to your vCO-Server: Open the vCO-Client, click on the small drop-down-Menu of the Packages-section, select “Import package…“, and import the com.vmware.samples.webservice.package from the WebServiceSample-Directory:

You should see a couple of new Workflows beeing added to your Workflow-Library:

7. Now you can run the other .bat-Files to Run a Workflow for instance (watch the vCO-client: You should see the new WorkflowToken appear!):

8. In the Example-client (built to samples.jar in step 3.) there are more calls, not all of them are a directly runable via a .bat-File. So for Your convenience you can copy the Inventory.bat to e.g. Samples.bat, and edit & replace the com.vmware.client.Inventory to com.vmware.client.%1 at the end of the (single) line. This allows you to call the other examples via the .bat instead of a long call with all the classpath-String.

To test, run Samples.bat FindAllByType (which should give you a list with all the VC:VirtualMachines in your Inventory):

A complete List with all examples:

  • FindAllByType
  • GetWorkflowEcho (broken, because of an hardcoded VC4:VirtualMachineGuestOsIdentifier … (you see: the examples-package contains some outdated stuff 😛  )
  • GetWorkflowOutput
  • Inventory
  • LaunchWorkflow
  • LaunchWorkflowWithInput

10. Now You can start examine, how the things work (or why not :mrgreen:  ) by digging into the sourcecode of the examples, which can be found in src/com/vmware/client:

Have fun! 😎