In this recipe, we will showcase how to run an Orchestrator workflow using PowerShell.
We need a Windows host that has PowerShell installed (which should be any modern version of Windows). VMware PowerCLI is not needed.
The PowerShell host needs to be able to connect to Orchestrator on TCP port 8281.
If you are new to REST or the Orchestrator REST API, you may like to work through the recipe Accessing Orchestrator REST API in this chapter first.
All PowerShell scripts shown here are also stored as a resource with the example package.
We will start by just running a workflow that doesn't require any input. We will be accessing the example workflow 07.01 Access via PowerShell.
- Create a new empty PowerShell script. For example, use Editor:
- Write the following code:
#some basic variables $usr = '[email protected]' $pwd = 'What4Ever' $vroServer = '192.168.220.12:8281' # Example Workflow "07.01 Access via PowerShell" $wfid = '48e10dcf-998c-4db7-b93d-144678e15368' # you need this to accept untrusted SSL certs. add-type @" using System.Net; using System.Security.Cryptography.X509Certificates; public class TrustAllCertsPolicy : ICertificatePolicy { public bool CheckValidationResult( ServicePointsrvPoint, X509Certificate certificate, WebRequest request, intcertificateProblem) { return true; } } "@ [System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy # you need to add TLS12 for vRO 7, else you cant establish a secure connection [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 #we build the BASIC authentication header. function ConvertTo-Base64($string) { $bytes = [System.Text.Encoding]::UTF8.GetBytes($string); $encoded = [System.Convert]::ToBase64String($bytes); return $encoded; } $token = ConvertTo-Base64($usr+":"+$pwd) $auth = "Basic $($token)" # we build the headers we need to call the REST flow $headers = @{"Authorization"=$auth;"Content-Type"="application/json"} #build the URL we are connecting to $URL = "https://"+$vroServer+"/vco/api/workflows/"+$wfid+"/executions" #invoke the run of the workflow via REST $ret = Invoke-WebRequest -Method Post -uri $URL -Headers $headers -body " {}" #Show the raw response of the run Write-Host $ret.RawContent - Save and run the script.
- Check in Orchestrator; a new execution should now exist.
We will now extend the preceding script to pass along some inputs. We will be accessing the example workflow 07.02 Access via PowerShell (Input).
- Make a copy of the preceding script and edit the copy.
- Just above the
Invoke-Webrequestline, enter the following code. Exchange the$inputcontent for the name of one of your VMs:#build body $input="VMware" $body='{"parameters": [{"name": "vmName","scope": "local","type": "string","value": {"string": {"value": "'+$input+'"}}}]}' - Replace the
Invoke-Webrequestline with the following:#invoke the run of the workflow via REST $ret = Invoke-WebRequest -Method Post -uri $URL -Headers $headers -body $body - Save and run the workflow.
- You should now see in Orchestrator that the workflow has been run.
We want to get the output of the workflow. We will be accessing the example workflow 07.02 Access via PowerShell (Input):
- Make a copy of the preceding script and edit the copy.
- Enter the following lines below the
Write-Hostline:#sleep for 20 seconds, to make sure the workflow finished Start-Sleep -Seconds 20 #get the execution ID from the reply $URL=$ret.Headers.Location #ask Orchestrator to give us detail of the workflow $result = Invoke-WebRequest -Method Get -uri $URL -Headers $headers #covert and get the output $outputObj=($result.Content).Replace("output- parameters","outputparameters")|ConvertFrom-Json $output=($outputObj.outputparameters[0]).value.string.value Write-Host $output - Save and run the workflow.
Using PowerShell to start Orchestrator workflows isn't that difficult as soon as you understand how to build the request lines and the content.
The basics are the same for all REST operations. First, you need to create a POST to start the workflow, which will return an execution ID. With the execution ID, you can go and check the results of the workflow using GET.
The hard part is the input variables: here you need to be a bit more careful. The JSON object that is the input isn't that easy to get. In the preceding code, I pushed it into one line, in the recipe, Accessing Orchestrator REST API in this chapter is the fully expanded code.
Using the ConvertTo-Json PowerShell function you can build the JSON body in a more dynamic way from a PSObject.
The return JSON is quite a beast to handle in PowerShell; one reason is that the variables are stored under output-parameter and using $outputObj.output-parameters will result in an error, as PowerShell expects a function called output-parameters. That's why I'm using a dirty trick and renaming the parameter (replace function) before converting from JSON.
Here is a nice little addition. The following do/while loop will wait until a workflow has finished. You can test it with the workflow 07.03 PowerShell WAIT for it.
#wait until the workflow has finished
$URL=$ret.Headers.Location
do {
Start-Sleep -Seconds 5
$result = Invoke-WebRequest -Method Get -uri $URL -Headers $headers
$status=($result|ConvertFrom-Json).state
} until ($status -eq "completed")
- Accessing Orchestrator REST API in this chapter
- Working with Powershell in Chapter 10, Built-in Plugins
- Working with REST in Chapter 9, Essential Plugins
- Accessing the Orchestrator Control Center API via REST in this chapter
- Burke Azbill post on how to do the same using Python and Perl: http://bit.ly/vroClientScripts
The example workflows 07.01 Access via PowerShell, 07.02 Access via PowerShell (Input) and 07.03 PowerShell WAIT for it.
As well as the PowerShell scripts stored as a Resource