Enabling VMware vCloud Automation Center XaaS with vCO dynamic types

You may have noticed that the vCO 5.5.1 release notes are listing a new feature called “Dynamic Types”

“Workflow developers are now able to explore the new Dynamic Types which currently is being shipped with Beta quality. They can easily extend vCenter Orchestrator plug-ins by adding their custom types accessible from the scripting API. New types become available in the inventory right after creation and they could be directly leveraged from the vCAC ASD context as part of the cloud provisioning process and XaaS definition.”

This article explores how the Dynamic Types can be leveraged to create your own mini vCO plug-ins without having any Java development skills.

vCloud Automation XaaS (Anything as a Service)

One of the most powerful vCloud Automation Center feature is XaaS (Anything as a Service). It gives the ability to request, approve, provision, operate, and decommission any type of catalog items (I.E storage, applications, accounts, anything you can provide as a service).

The vCloud Automation Service Architect designs a service blueprint calling a provisioning workflow outputting a custom resource. This custom resource is mapped to a vCO inventory object item referencing the orchestrated system entity. It can then been used as an input of the workflows defining the operations available for this item and for the decommissioning workflow.

When not used contextually an inventory item is presented to the end user as an input field with a tree view or a list view selection.

An inventory item type is statically defined with a type name (I.E VirtualMachine), a list of properties (I.E name, state) and is prefixed with the vCO plug-in name (I.E VC:VirtualMachine). This definition is contained in the plug-in description file (VSO.XML). The more vCO plug-ins are installed the more inventory type vCO will be able to manage.

It is possible to get additional plug-ins from VMware and partners with using the VMware solution exchange or by creating a plug-in with the Java based plug-in SDK.

If there is not out of the box vendor plug-in and if resources / Java development skills are not available to develop a plug-in it is still possible to rapidly design workflows to orchestrate systems exposing a web service using the SOAP or REST plug-in. These will allow pulling remote systems entities information and operating them as part of the vCloud Automation Center Infrastructure as a Service lifecycle. It is great but then it is missing the inventory object required by vCAC XaaS catalog items and day two operations.

Dynamic Types is a new vCO feature shipped starting with vCO 5.5.1 (experimental) allowing creating inventory types dynamically without doing any Java development. It brings together the quick implementation of the REST / SOAP plug-ins with the convenience of using inventory objects leveraged by vCAC XaaS.

This article

  • Describe the Dynamic Types toolbox provided by VMware
  • Explains the concepts involved in creating a plug-in using the DynamicTypes
  • Step you through the plug-in generator package I created to accelerate dynamic types plug-ins development time.

The Dynamic Types toolbox

A set of workflows are provided as part of the Dynamic Types plug-in to help design a plug-in:

  • Define / Update / Remove Namespace
  • Define / Update / Remove Type
  • Define / Remove Relation
  • Export / Import configuration / type definitions

Here us the complete list of these workflows :

The sequence is to create a namespace in which types are created and relations between these types are established.

Using these workflows will update the Type Hierarchy shown in the vCO inventory under “Dynamic Types” and also the namespace inventory of the objects if there are any. Below is an example of a Type Hierarchy:

The plug-in configuration is written in the config resource element in the Library/Dynamic Types folder. A JSON editor can be used to edit the exported config resource. It is then possible to create / update / delete namespaces, types and relations by updating the resource element. It is recommended to make a copy of this file every time the resource file is exported to be able to roll back to the last working version in case of an unwanted configuration change. Below is an example of a plug-in configuration file displayed in a JSON editor. There are several JSON viewers editors available online.

The export / import functionality is a convenient way to save the plug-in configuration in a resource file that can be included in a package so the plug-in configuration can be loaded on another vCO server.

The concepts for building a Dynamic Type plug-in

Building a Dynamic Type plug-ins requires understanding the vCO elements that have to be created and the back and forth communication between vCO and the remote system.


The first and very simple step is to create a namespace. It is the root element of the plug-in and defines the prefix of the inventory objects. You can run the “Define namespace” workflow. For example I created an iTop namespace to manage the Combodo iTop application.

A REST or SOAP host

While it is possible to integrate with a remote system in different ways most applications offer a REST or SOAP web service. Running the “Add a new host” (SOAP or REST) workflow with selecting the right authentication method and the credentials. Refer to the API documentation to do this configuration and use a test operation to make sure the connection and authentication work as expected.

findAll, findById, findRelation

Each of the plug-in object type of the plug-in requires creating REST or SOAP operations to:

  • List all objects for a given type (findAll) : This is used by the list view drop down
  • Get an object for a specific id (findById) : This is used to resolve and display the object in an input field and between each step of a worklow. This operation requires having an id parameter that is represented as {id} in the operation string
  • List child objects of a specific parent object: This is used in the inventory tree view and is invoked when an inventory item is unfolded

To create these operations it is required to find the target system SOAP / REST API URL and use the workflows “Create a new operation” (REST / SOAP).

To invoke these operations and as a result create new inventory dynamic types objects it is required to create three vCO actions:

  • findAll:

  • Input = object type

  • Output = array of Dynamic objects

  • findById:

  • Input = object type and Id

  • Output = Dynamic object

  • findRelation:

  • Input = object type and Id

  • Output = array of Dynamic objects

Invoking the operations above will result on a string based HTTP response content. Typically this will be an XML or JSON (JavaScript Object Notation) string representation of the object including its properties.

These properties need to be extracted and passed as parameter of a makeObject() method.

vCO supports a programming language extension called E4X (ECMAScript for XML) that adds native XML support to JavaScript AND also does natively convert JSON to JavaScript object. This makes it convenient to extract the object properties without complex parsing.

The makeObject method has 2 mandatory parameters (ID and name) and optional object properties (using a vCO Properties() object).

Note that the properties of a DynamicTypes are of simple type. You cannot set a property with a javascript object.

There is one extra action that is needed as well : hasChildrenInRelation is used to define if an inventory object has children or not (represented in the tree view by a >) and calls findRelation when returning true. A simple implementation of hasChildrenInRelation can be to test if findRelation returns more than 0 objects.

It is also possible to use workflows instead of actions during development time to see if the workflows are called and run as expected. However it should not be considered for production for performance and reliability reasons. An action is several times faster to run than a workflow and a workflow needs to resolve the objects requiring calling the findById workflow. This may start endless loops.

Once the four actions for a given object type have been successfully tested it is possible to create the Dynamic Type object definition using the provided “Define Type” workflow. This consists in setting a type name, an icon, the object properties and the mapping to the four actions.

For presenting properly in the inventory you need to create objects that will show a folder type and create a relation where this folder object is the parent of the object you created. For this the findRelation action will return an array with a single object.

Once completed you should be able to:

  • Unfold the dynamic Types inventory and see under the namespace the folder object, unfold it and see a list of objects.
  • Use this type as an input / output parameter of a workflow. When dealing with an input seeing a list view with all the objects.

If findAll and findRelation are too network intensive and result in slow inventory updates it is possible to use the putInCache() / GetFromCache() methods provided as part of the plug-in to cache the array of objects to be returned. A cache expiration policy can be designed to avoid not updating the inventory for too long.

CRUD operations

Having an inventory object makes it easy to select and get properties. Creating, updating, deleting, calling a method on the object requires some additional work.

For each of this operation it is necessary to create the SOAP/REST matching operation. Updating, deleting, calling a method will require passing the object ID.

Once you have created one of this operation you need to create an action that:

  • Get the ID from the object that is an input parameter of the action (except for create)
  • Invoke the SOAP / REST operation with passing the ID
  • Getting the result / do error checking
  • Return the created / updated object
  • Invalidate the inventory when necessary (on update / delete)

The created actions should be provided as part of library workflows going with the plug-in.

After some time depending on the number of object that need to be implemented and the number of crud operations you can expect a result like this Combodo Itop plug-in implementation:

The plug-in generator package

This is my attempt to make the Dynamic type plug-in development as simple and as quick as possible. Depending on the orchestrated technology it is possible to create a plug-in without writing a single line of JavaScript code. Here is how it happened:

  • I implemented a first plug-in (iTop Combodo) including a lot of objects (close to 90) in an inventory including multiple levels of cached objects with using a single set of findAll, findById, findRelation, hasChildrenInRelation.
  • I have isolated all the re-usable scripting, replaced all the specific scripting by generic scripting plus configuration files.
  • From these building blocks I have created a plug-in generator workflow and tested it successfully with the Twitter API without having to write any specific scripting.
  • I improved it to make it more interactive, adding several steps to check on the data returned and tested it against the vCO API. This was less straight forward since some queries did not return the objects in the format I was expecting. Knowing this would be a common issue (there is not such thing as API consistency) I have implemented placeholders to replace the default actions I provide to invoke a request and to deserialize the objects returned by the queries.

At this moment it is designed to handle HTTP REST hosts returning JSON strings. Using XML is certainly possible using custom actions. Using SOAP requires more work but a lot of the scripting included should provide a good basis to someone willing to adapt this solution to SOAP.

You can find the Dynamic Types plug-in generator package from the VMware communities.

Why is it beta?

You should use this technology in your labs and / or for developing and not in a productive environment yet.

Here are some of the known issue to be fixed in next releases:

  • vCAC 6.0.X cannot yet request a catalog item linked to a dynamicType via a resource action

On the DynamicType plug-in & vCO:

  • No way to refresh the inventory view when objects are updated / deleted
  • Duplicate objects when using more than a single namespace
  • Performance & stability to be improved