Dynamic Types have always seemed to be a mystery to alot of people who use vRealize Orchestrator (vRO). Sometimes people don’t understand why you might need them and other times they just seem way to complex to figure out how they work and how to implement them.
What and Why
Dynamic Types enables you to form a sudo plugin within vRO for an object type that either has no native vRO plugin or for when a plugin exists but doesn’t provide all the properties you want available on an object or for when you want to return a custom object back to vRA which it does not natively support.
A typical use case that I come across regularly is when vRA is being used with vRO and with XaaS for custom services, and the objects of the custom workflows have no supported defined object type within vRA. This means we have no managable object that can be registered within vRA that represents the product of a custom service execution. Without a managed object a user cannot see the product of what they have requested and then they cannot drive a day 2 action from their product.
Example Overview
To better illustrate, lets define a sample use case for Dynamic Types. We have a requirement to provision new datacenters within vCenter and to drive this from vRA. We want the requesting user to see the datacenter objects within vRA and be able to run day 2 operations against the datacenter so that they do not have to log directly into vCenter. To do this we will create a Dynamic Type that respresents vCenter Datacenter objects and associated workflows that the object searches.
The NameSpace
The namespace is the root of an object tree. It contains a hierarchy and one or more dynamic types may exist within a namespace depending on what you require. Each object type has a relationship with one another (parent, child etc). You can define multiple namespaces however objects in one namespace will have no relationship to objects in another.
In our example we will create a namespace for our vCenter Datacenters.
Switching to the inventory browser we can now see our namespace has appeared.
Defining the Dynamic Type
At this stage the meaning of defining a dynamic type is purely deciding on the name of the object type, setting the parent namespace and deciding on any properties you want the object to have. For this use case I have decided I want the object hierarchy to be:
Namespace -> vCenter -> Datacenter
To implement this we will need to define a Dynamic Type for vCenters and Datacenters using the “Define Type” workflow. For the vCenter object I have decided it would be useful for it to have 2 properties holding the FQDN and the IP address so I have added property labels for these. You can add whatever you want here, just remember you will need to add code to fetch and populate the information.
I have setup a dedicated workflow folder for each dynamic type to host our stub workflows (more on these later).
Once the workflow has completed the dynamic type should be visible in the inventory explorer.
The above steps can now be repeated for the Datacenter dynamic type. In this case I will add a property for the parent vCenter. Our inventory explorer now looks like this:
Dynamic Type Hierarchy
Now that we have both of types defined we need to define the hierarchy between them. Currently there is no hierarchy as both types are listed on the same level as shown in the inventory explorer. To define our hierarchy we need to run the “Define Relation” workflow. I find it useful to name the relation as per parent-child relationship.
Now the hierarchy looks as follows:
Populating the Object Tree
Objects are populated in the object tree by running workflows, the stub workflows created by the “Define Type” workflow we ran earlier to create each dynamic type. When the stub workflows are created it is useful to place them in numbered sub folders so that you know the order in which they will be executed as you expand the object tree.
Our workflows currently reside in the following structure. The stubs under the vCenter folder will be executed at the first level in the tree and the stubs in the Datacenter folder will be executed at the second level.
The “Find Relation vCenter Datacenters-vCenter” workflow executes automatically when the object tree is refreshed in the inventory explorer. We need to tell this workflow what to do and when to do it when it is called.
The first thing to tackle is to get all the vCenters as the vCenter object is at the top of the hierarchy we defined. The process of defining the vCenter type has created a stub workflow for this called “Find All vCenter Datacenters-vCenter” so we can place the code that looks up the vCenters in there and then call it from “Find Relation vCenter Datacenters-vCenter”. We also need to tell the workflow to get the Datacenter objects underneath each vCenter object by calling the “Find All vCenter Datacenters-vCenter” workflow.
Note see next section for the workflow contents
We only want the relation stub workflow to retrieve content for the root object tree refresh and first object level selection so we also need to place some conditions in the workflow so that no other levels of hierarchy are serviced by this workflow.
Lastly we need to cast whatever output is generated back to generic dynamic type objects. This is our “Find Relation vCenter Datacenters-vCenter” stub workflow now. It first checks to see if it’s being called by the root and if so fetches all the vCenter objects. If it’s not being called by the root but is being called by an object in the relation “vCenter-Datacenter” then it fetches all the datacenter objects. For anything else it does nothing.
Now that we have defined the workflows to call in our find relation workflow we need to tell the object tree whether to expand to show child objects and in under what conditions. The “Has vCenter Datacenters-vCenter Children in Relation” workflow allows us to provide some code for this function. In our example we are going to always offer the vCenter object the ability to expand to a Datacenter object so this workflow is set to return true always (you might want to use more intelligence in a production scenario).
Getting the Objects for the Tree
In the previous section I referred to calling 2 stub workflows to fetch our vCenter and Datacenter objects in order for them to be displayed in the object tree. Lets look at the contents of these now.
This is our “Find All vCenter Datacentres-vCenter” workflow. The VC code is less important than what we are doing with it. The “makeObject” method is what we use to define a new object. It’s parameters dictate which namespace, object type, id and name to assign to the object. In this case we’re working in the “vCenter Datacenters” namespace, “vCenter” object type, the vCenter name as the object ID and the object name.
Our “Find All vCenter Datacenters-Datacenter” is similar however it has a key difference. We take the id of the parent object as an additional input so when we are looking for datacenters we only return those that relate to the parent vCenter.
If we refresh our inventory explorer object tree now we see the following.
Using Dynamic Types in Workflows
In our use case we have a need to return a dynamic type object as the output of a workflow. Up until now we have just been dealing with the object tree but now we need to add some functionality to allow our dynamic type objects to be used.
The “Find X By Id” workflows are responsible for returning a dynamic type object based on a supplied ID. In our example we are going to need to return a datacenter dynamic type object so we will look at the “Find vCenter Datacenters-Datacenter By Id” workflow.
This workflow will fire whenever anything tries to find the object using it’s ID which includes a workflow or vRA. For us to find the datacenter we need to take it’s ID (in this case the datacenter name) and search for it through all of our vCenter instances. When we find a datacenter with a matching ID (i.e. the name) we will make a dyanmic types object for it and return that object to the calling process/workflow.
The last part is for a workflow to be able to find the dynamic types object so that in our use case it can have it as a workflow output and returned to vRA. To do this we will create a test workflow to simulate a master service which will make use of the “getObject” method.
Here we are supplying the datacenter name we want to get the DT object for along with the namespace and dynamic types object type.
Everytime we execute our test workflow the “Find vCenter Datacenters-Datacenter By Id” workflow will fire in the background. The output object on our test workflow has all the properties attached as set by “Find vCenter Datacenters-Datacenter By Id”.
We can now use this dynamic type within vRA and have the associated objects show in the “Managed Items’ tab for a user.
vnuggets 