I wanted to rebuild my environment in vRealize Automation to use 7.6 as I had been using 7.3 for quite a while. When I had finished installing the appliance along with the IaaS hosts, I noticed that running the “vSphere Initial Setup” XaaS form would fail to perform the initial configuration. I attempted running the workflow in both vRA along with the embedded vRO to see if maybe something was wrong with the XaaS form, however much to my dismay that wasn’t the case. Some information on my environment and what I used.
The vRA environment is a lab, therefore I used the default tenant
vCenter endpoint is called “vcenter01”
Agent name is called “Agent01”
The login for the vCenter endpoint was the default email@example.com
The requester was configurationadmin from the out of box setup in the final installation steps
Running the workflow would step through about half of the built-in scripts and yield the following logs (I stripped out the preceding ones for simplicty, else this post would be exceptionally long):
What stood out to me was the “Agent entity with name vcenter01” found. I noticed this was the endpoint name inputted in the XaaS form initially, along with the workflow if ran from vRO. So my next step was to drill down what was going on. I first wanted to identify the dependencies and noticed the only attribute used is the vCAC:VCACHost variable, which was easy to map as it was simply vRA. I cloned the script into its own workflow and recreated the bindings. It did not hold and outs either (excluding the attribute) which led to the following:
I ran this workflow on its own to see if it would yield the same error. The above error code was thrown once more and what stood out to me was the ‘vcenter01’ was found. The endpoint however, is called ‘vcenter01’ but not the agent. In the next attempt, I decided to try it and input the Agent name instead because I noticed one particular oddity within the script.
The “System.log” portion caught my attention as it’s simply outputting whatever the in value is. It’s never actually performing any validation if the Agent was found. So when the resultEntities is trying to pull data, it’s yielding an undefined value. Subsequently, that was when I tried inputting “Agent01” as the endpoint name instead for “endPointName.” This worked and it found the Agent and began the data collection process. A bit strange, so I gave it a try on the original workflow.
Of course, an easy solution is typically not the right one. This failed because as I assumed, the ‘vcenter01’ endpoint name is used in previous scripts. A dilemma really, but given that no “Outs” were needed in the data collection portion of it, I figured I could cobble a way to at least satisfy it. While not the most elegant way, I created an attribute string named “globalAgentName” and assigned it a static value of “Agent01” then tied it to the visual binding region.
The script of course also removed and mention of “endPointName” and substituted it with the “globalAgentName” attribute to pass the agent entity name instead. This worked! The inventory collection began to function without any issues, and I was able to invoke the workflow for the inventory collection at any point. The next part was to create this as a XaaS form to request it on the vRA self-service portal.
I proceeded to clone the vSphere Initial Setup, add in the modifications made and start adding the extra functionality needed for the Agent reference. The first thing I wanted to do was convert the attribute back to just an “IN” element, that way I could integrate it within the presentation form and nest it under the vCenter server settings as a mandatory input.
Now instead of being hardcoded in, the individual can pass any name they want.
The next step was to create the XaaS form on the design tab of vRA. Adding the workflow was a simple process to do, and vRA did a fantastic job of generating all the form elements required. The following images depict the steps I took:
We can see here that the new workflow is there with the additional input variable I added.
I changed the text here a little to differentiate from the original workflow.
The form automatically imports the presentation from the vRO, which saved a lot of time! And further it showed the new input variable I added.
Given this isn’t provisioning anything but only configuring the environment, no managed machines are being instatiated so we’ll leave it as “No provisioning.”
Simply part, just adding it to the XaaS category.
Now with that all complete, I published the blueprint and added the entitlements to it. When performing the request of the XaaS object, I was able to see the token worked just fine in vRO, the endpoint was added in vRA along with all inventory objects.