Home > Blogs > VMware vCenter Orchestrator Blog


How to manage everything as a service with vRealize Automation ?

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

Requesting a DNS host Record

 

Operating a DNS host record : Removal action

 

  • 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.

Requesting an application blueprint including a DNS host record XaaS component

It can be operated from there and will be decommissioned automatically with the application

Operating a DNS host record : Removal action

 

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.

Adding a custom DNS Host resource mapping to a Microsoft DNS.resourceRecord vRO Dynamic Type

New resources can be provisioned using an XaaS blueprint that is basically a mapping to a vRO workflow that create and output the object

Adding an XaaS blueprint

Resource actions are mapping to vRO workflows that take a custom resource as an input and operate it.

Adding an resource action

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.

vRO Microsoft DNS inventory side by side with Microsoft DNS Manager inventory

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.

If you open the Orchestrator API explorer you can see it lists for each plug-in the finder and scripting objects. The finder object has text based properties listed to the end user in the input of the workflow, the scripting object can have more properties, non text based (JavaScript objects ) and also provide methods to act on this object.

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:

 

Java Dynamic Types
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.
Can leverage Java libraries but then has dependencies on these Can leverage vRO JavaScript available via platform and plug-ins
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.

Conclusion

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

 

One thought on “How to manage everything as a service with vRealize Automation ?

  1. Alex

    Wow! First of all – i’m glad to see something about Dynamic Types. Thank you for details and incredible detailed post about DNS plugin. I’ve been struggling for a long time to find details/docs/anything about Dynamic Types and a proper way to use them with vRA. Please publish more details about this stuff! And if you by any change get a time to explain “Dynamic Types Plugin generator” – it would be great. A lot of customer would like to use vRA with 3-rd party systems, so Dynamic Types is the only way to make it work. I just don’t see any reason why this powerful stuff is keeping in a dark room far away from customers 🙂

Comments are closed.