A common question I get asked when working with customers is why are they unable to see recently created vRealize Orchestrator (vRO) action when creating vRealize Automation (vRA) Property Defintions. For example, let’s say I created the vRO action below:
The main things to notice are:
- The action is called getNames and is under the io.orchestration package
- The return type is Array/string
In my vRA Property Definition I’ll set the Data type to be a String and Display as to Dropdown as shown:
Now if I select set Values to External values (a vRO action) and press Select, I’ll be presented with a list of vRO actions:
Here we can see the same vRO action (getNames) we created in vRO:
Before displaying the Select Script Action screen above, vRA queried vRO for all actions that have a return type of Array/string. This is because in the Property Definition I’m going to be displaying a dropdown box of strings.
If I was to change the Property Definition to use a Data type of Integer:
and tried to use External values, I wouldn’t be able to see my vRO script action:
So as you can see your vRO action’s return type must match the data type defined in your Property Defintion otherwise you’ll be unable to see your vRO action.
Because vRA allows you to configure a global vRO server and vRO servers per tenant, sometimes users will create a vRO action on one vRO server, but their vRA tenant will be configured to be using a different vRO server. If you have ssh access to the vRO servers, you can confirm that you’re working with the correct vRO server by running the following command as you attempt to browse vRO actions from your Property Definition:
tail -F /var/log/vmware/vco/app-server/localhost_access_log.txt | grep getNames
If you’re on the correct server, you’ll see results such as these:
vra73a:/var/log/vmware/vco/app-server # tail -F localhost_access_log.txt | grep getNames
2017-12-07 03:55:28.677+0000 127.0.0.1 – – [http-nio-127.0.0.1-8280-exec-1] “GET /vco/api/actions/com.vmware.o11n.plugin.dynamictypes.configuration/getNamespaceByName HTTP/1.1” 200 1011 194
2017-12-07 03:55:32.875+0000 127.0.0.1 – – [http-nio-127.0.0.1-8280-exec-13] “GET /vco/api/actions/io.orchestration/getNames HTTP/1.1” 200 827 196