WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / Automation / Using vRO REST API to execute a workflow with SDK objects

Using vRO REST API to execute a workflow with SDK objects

03.13.2020 by William Lam // 3 Comments

I was working on something last week which involved vRealize Orchestrator and I wanted to execute a vRO worklfow but rather than using the UI, I wanted to use the vRO REST API. Although there are a couple of blog posts such as this one which demonstrates how to use the vRO REST API, they all use a very simple workflow that only contains string inputs. In my opinion, this does not actually reflect practical workflows which usually contains a mix of strings but also SDK-based objects like vSphere VMs, ESXi hosts, Networks, etc.

It actually took me awhile to wrap my head around how to call these more complex workflows using the vRO REST API and after a ton of trial/error and some help from Kasey Linden and one of the vRO Engineers, I now have a method in which users can follow to identify the required payload for a given vRO workflow when using the vRO REST API. The instructions below is using the latest vRO 8.0.1 release which has a new HMTL5 UI, it has been awhile and I am not sure when this new UI was introduced but the instructions may work for older clients but I would recommend standing up the latest version for developing your automation.

Step 1 - Retrieve the vRO workflow ID by selecting the workflow in the vRO UI. In the example below, my Tag a VM workflow ID is 9d95c7f5-a563-413f-af42-fd7e09275216

Step 2 - Manually execute the workflow once and retrieve the execution ID as highlighted in the screenshot below. In my example, the execution ID is 03ae74a3-2466-4607-aded-b6514f358fae


Step 3 - Next we will use the vRO REST API to retrieve more information about this manual execution which will give us details about the required payload structure. In my example, I am using Postman but you can use any REST Client including cURL. You will need to perform a "GET" on the following URL example https://[VRO-SERVER]:443/vco/api/workflows/[WORKFLOW-ID]/executions/[EXECUTION-ID]

In my example, here is what the URL looks like substituting the required fields: https://vro.cpbu.corp:443/vco/api/workflows/9d95c7f5-a563-413f-af42-fd7e09275216/executions/03ae74a3-2466-4607-aded-b6514f358fae and if the operation was successful, you should see a section called "input-parameters" which describes the exact structure and payload of the input that you had provided when using the vRO UI to execute the workflow.


As you can see, when dealing with SDK objects like VM input within vRO, you need to construct a more complex JSON property which is not very well documented. In fact, I came to learn that even the results here is also a little missing leading. The href property is not absolutely required but if you include that, it will override the id field which along with the type are the two mandatory inputs to properly construct this object.

To be explicit, below is a valid payload that can be used and notice even the syntax for id can have two forms: [VC],id:[VM-MOREF-ID] or [VC]/[VM-MOREF-ID] which just adds to the confusion. I prefer the latter format as its easier to understand and now that we know now to construct the VC:VirtualMachine JSON property, we now have all the pieces to execute this workflow using the vRO REST API.

"value": {
   "sdk-object": {
      "type": "VC:VirtualMachine",
      "id": "mgmt-vcsa-01.cpbu.corp/vm-2660"
   }
}

Step 4 - Finally, putting all this together we have the following payload (be sure to replace the values with your respective workflow) and then we perform a "POST" to https://[VRO-SERVER]:443/vco/api/workflows/[WORKFLOW-ID]/executions which will execute the vRO workflow via the vRO REST API.

{
    "parameters": [
               {
			"value": {
				"sdk-object": {
					"type": "VC:VirtualMachine",
					"id": "mgmt-vcsa-01.cpbu.corp/vm-2660"
				}
			},
			"type": "VC:VirtualMachine",
			"name": "vm",
			"scope": "local"
		},
		{
			"value": {
				"string": {
					"value": "Application"
				}
			},
			"type": "string",
			"name": "categoryName",
			"scope": "local"
		},
		{
			"value": {
				"string": {
					"value": "Photon"
				}
			},
			"type": "string",
			"name": "tagToFind",
			"scope": "local"
		}
	]
}

In my example, here is what the URL looks like substituting the required fields: https://vro.cpbu.corp:443/vco/api/workflows/9d95c7f5-a563-413f-af42-fd7e09275216/executions as shown in the screenshot below


If everything was successful we should see the workflow execute successfully via the vRO REST API and we can also confirm by using the vRO UI. Once I understood how the object should be constructed and the actual required values and syntax, this was not too difficult but I can say it was not a trivial thing to figure out. I should also mention for those looking to automate vRO workflows via vRO REST API, check out Jonnathan Medd awesome PowervRO module which makes it very simple to call into a specific workflow via the vRO REST API, but you will still need to create the required payload and using this blog post, you now have a way to construct it! Happy vRO'ing and stay tuned for how I will be using the vRO REST API as this is not the end of it 🙂

More from my site

  • Is there a vSphere REST API for ...
  • Getting Started with the Application Transformer for VMware Tanzu REST API
  • Integrating vCenter Event Broker Appliance (VEBA) with vRealize Orchestrator 
  • Configuring Standalone vRealize Orchestrator with VMware Cloud on AWS
  • ESXi host with network redundancy using NSX-T and only 2 pNICs?

Categories // Automation, vRealize Suite Tags // REST API, vrealize orchestrator

Comments

  1. *protectedSofi says

    07/30/2020 at 5:48 am

    Good article, thanks for sharing...
    However, how to translate and find out from a normal vm name (in vc) to vm-2660 (for example)?

    Reply
    • *protectedSofi says

      07/31/2020 at 6:41 am

      I have found it, vm-2660 is actually the vm id 🙂

      Reply
  2. *protectedWyko ter Haar says

    10/30/2021 at 5:40 am

    Thanks for the article! This helped me get past a roadblock I had!

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...