In this three part guide I will show you how to extend vRealize Automation 7 to use vRealize Orcestrator workflows as part of the provisioning process. This could be used for something as simple as running a script in the guest to more advanced use cases like talking to an external database or a load balancer. In this guide I will show you an overview of the data flow and architecture as well as a simple hello world example. From there you should have the working knowledge to be able to start to design your own integration’s.
vRA 7.x new event driven architecture
vRealize 7 introduced a new feature named the Event Broker, previously in 6 and older versions we used the workflow stubs. While some of the workflow stubs are still in vRA 7 they are there for legacy reasons and the old method of extensibility should not be used as it may impact future upgrades. With that said the new event broker is in the vRA portal now and is much easier to configure then the old design center.
Basics of vRA to vRO extensibility
Extensiblity is about passing property’s or (MetaData) from one system to another. We use the meta data as inputs for the workflows that we want to run in vRealize Orchestrator. The event broker allows us to run a workflow or several workflows at an stage in the provisioning process. For example after the machine is provisioned but before the end user has access to it we may want to run a script in the guest to install and configure some back up software. Once this is complete and installed successfully we can move the request on and hand it to the requester.
How do we get properties from vRA to use in vRO workflows?
vRA uses custom properties, these are usualy in a type of format called a string, vRO uses attributes that may be a string, array, workflow token, vCAC:Machine and so on. So we need to first import all the custom properties, then create a scriptable task to convert those to attributes. (Don’t worry, in part II I will provide all this for you, this is just an overview. NOTE: You can create your own custom properties or use the generated custom properties that vRA reserves (For example the ip address of the provisioned VM) for a full listing see here: http://pubs.vmware.com/vra-70/topic/com.vmware.ICbase/PDF/vrealize-automation-70-custom-properties.pdf
How do we create input data to run vRO workflows?
You’ll notice that vRO workflows always want an attribute as an input. Because we have all the custom properties we have most of this information as long as we converted them to attributes, for example the VM name, IP address, user and password can all be found in a custom property. NOTE: Not all the attributes for a workflow will come from vRA custom properties, sometimes we need to manually create them. If they are static entries like script timeout or working directory you can easily create them manually, other things like script name and script location you may want to use a custom property in vRA so the user has more flexibility and you have less blueprints.
How do we automate to other non-VMware systems?
vRealize Orchestrator uses Plugins to automate both VMware as well as non-VMware technology and solutions. Some of these are free and provided when you install vRealize Orchestrator, some are available from the Vendor as a part of your license agreement or they are just freely available. Some are made by a third party and have a cost. For a full listing of the plugins available and where to get them click here http://www.vcoteam.info/links/plug-ins.html