One of the great feature of vRealize Automation is that it can be extended way beyond your virtual infrastructure to manage Anything as a Service (XaaS). This means using its self service portal for provisioning, running day two operations and decommissioning any type of services. Just think about the many different services an IT organization delivers to its end users. many distinct processes, people and interfaces involved that could be offered as a service.
XaaS comes into two flavors in vRA:
- An XaaS catalog item, similar to an application blueprint can be requested directly. Once provisioned it is listed under the items tab where it can be opened to show properties and operated. The vRA service designer the service with defining the details level and operations users can perform and entitle these to different user groups
- An XaaS component can be added to an application blueprint. When requested by a user the XaaS component get requested as well and is displayed as part of the application deployment.
It can be operated from there and will be decommissioned automatically with the application
How does this work ?
vRA can be extended to manage new entities that are called custom resources. Technically a vRA custom resources maps to a vRO plug-in inventory object.
New resources can be provisioned using an XaaS blueprint that is basically a mapping to a vRO workflow that create and output the object
Resource actions are mapping to vRO workflows that take a custom resource as an input and operate it.
vRA displays with updating in real time the properties of the resources provisioned for each users in the items tab by leveraging the vRO plug-in inventory
How does a vRO plug-in work ?
One of the function of a vRO plug-in is to provide an inventory of managed objects: in a similar way vCenter displays an inventory of Hosts, VMs, networks and storages vRO can manage any type of objects. Once there are new managed objects in the inventory you can create CRUD (Create, Rename, Update, Delete) workflows to operate them.
The first thing a vRO admin does to configure a plug-in is to add a management host. For example adding a vCenter Host to its inventory so vRO can query vCenter API to populate the vCenter inventory.
vRO knows how to query the child resources of the management host because there is in each vRO plug-in a configuration file that documents what kind of child objects are to be discovered under a parent object and how to query the child objects properties. This is done using the plug-in findRelation() method.
When you select a plug-in object in one of vRO workflow input field:
- Using the tree-view a plug-in method called hasChildrenInRelation() is called to show if a parent object has child objects then findRelation() is called to list the child objects.
- Using a drop down a plug-in method called findAll() is called to list all the objects of a given type under all the management hosts of a plug-in. The same findAll method is also called when programmatically calling Server.findAllForType([Type]) in a vRO scriptable task or action.
The selected object is called a Finder object. The vRO workflow engine uses this object unique ID to carry it between the different steps of the workflow. Whenever you use this object as an input of scriptable task or action a plug-in method called findById is called. findById will get the object properties as a Scripting object so they can be used programmatically. So basically the object properties are reloaded every time the object is used as an input.
Now you may wonder how the inventory and its hasChildrenInRelation(), findRelation(), findAll(), findById() methods are implemented.
In the case of a Java based plug-in :
- The inventory is described in the VSO.XML file contained in the plug-in .dar file (a dar file is a zip file format you can extract).
- The methods are implemented in Java. Part of the plug-in will consist in Java libraries used to interface with the management host API (for example HTTP libraries to interface REST APIs) or the library provided by the SDK provided by the vendor of the management solution.
There is another type of plug-ins called Dynamic Types.
- The inventory is described in a vRO resource element in a JSON format that can be edited by workflows that are provided with the Dynamic Types plug-in or edited in an external editor by exporting and importing back the resource.
- The methods are implemented as vRO workflows or actions. For example if you interface with a REST based API you can write an action leveraging the HTTP-REST plug-in to fetch the properties of the objects.
The difference between the Java plug-in and the Dynamic Types plug-in are:
|Closed source (Java binary)||Open source (Actions and workflows)|
|Scripting objects (Complex properties, methods)||The scripting object equals the finder object so there are no complex properties or methods.|
|Requires Java development skills||Requires scripting skills|
There are a lot of existing Java plug-in available from VMware and VMware partners from VMware web site individual product download pages or VMware Solution Exchange.
When there are no Orchestrator plug-in for a given technology there is the option to create your using the plug-in software development kit or Dynamic Types.
With this article I have demonstrated how vRealize Automation can be extended to manage the lifecycle of any service with XaaS and how it is leveraging vRealize Orchestrator plug-ins to do so.
For an in depth technical walk through on how I have created the Dynamic Types Microsoft DNS plug-in featured in the screenshots of this article please check this “How to create a Microsoft DNS Dynamic Types plug-in ?” article.
If you are interested by the Microsoft DNS Dynamic Types plug-in I have uploaded it on VMware Sample Exchange