Executing workflows and actions with the o11n-gateway-service API

o11n-gateway-service API

The Orchestration Gateway Service API (or o11n-gateway-service) was introduced in vRA 7.1 and provides a gateway to the vRO instance that is registered with vRA. It enables us to interact with vRO elements such as workflows and actions without the need to make external authenticated API requests.

The documentation that exists for this API is fairly comprehensive, however it’s not very forthcoming with some of the smaller details you need to get going. It took a fair bit of effort to work out the correct payload format for the requests so I thought it would be a good idea to share what I found.

Continue reading

PowervRA v2.2.0 – Invoking a vRA data collection

With the latest release we are pleased to provide you with the ability to start a vRA data collection from PowervRA!

Invoke-vRADataCollection takes advantage of the o11n-gateway-service endpoint which appeared in vRA 7.1.

From the documentation:

The orchestration gateway service provides a gateway to VMware Realize Orchestrator (vRO) for services running on vRealize Automation. By using the gateway, consumers of the API can access a vRO instance, and initiate workflows or script actions without having to deal directly with the vRO APIs.

The new function uses this service to execute the Force data collection workflow that is included as a Library workflow and part of the vRA plugin for vRO.

Continue reading

Using GithubReleaseManager to automate GitHub releases


GitHubReleaseManager is a PowerShell module that wraps up GitHub’s Releases API. It allows users to automate releases of their software by via the command line or by integrating the module in to build tools such as PSake.


The idea came about while working on another community project. Every release consisted of a number of manual tasks, one of which was publishing the release. While not complicated, it was always slightly tense for me as I wanted to ensure that all releases were consistent. The obvious solution was to automate this step and luckily, GitHub provide a really comprehensive API for managing releases. The module provides a way to create new releases and manage/update existing releases and assets.

In the future I will post more articles covering how to use each of the additional functions in the module.

Continue reading

Defining multiple Output Types in a function

Defining an Output Type for a function is a useful way to inform other users or tools about what to expect once the function has been executed.

While doing some research I came across the documentation for the OutputType attribute and noticed that it’s possible to set an Output Type per Parameter Set. You can use the ParameterSetName property in the declaration. For example:

[OutputType('[System.String]', ParameterSetName="A")]
[OutputType('[System.Array]', ParameterSetName="B")]

    [Parameter(Mandatory=$true, Position = 0, ParameterSetName="A")]

    [Parameter(Mandatory=$true, Position=1, ParameterSetName="B")]

The OutputType property of Get-Command reflects each type specified above:

Personally, when designing a function, I always try to ensure that it has a single purpose and will only return a single type. However, in the case where this is unavoidable and you are using Parameter Sets to categorise your parameters this is a neat way to do the same with your Output Types.

Quickly list supported API versions for ARM resource types

One of the things that I found the most challenging when learning how to create Resource Manager templates was trying to understand which API versions to use for my resources. The documentation is pretty clear and states that most of the time we should be aiming for the latest API version. It also contains examples showing how to get the information. For example:

((Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Web).ResourceTypes | Where-Object ResourceTypeName -eq sites).ApiVersions

Excellent.. but copying and editing the code every time I wanted to retrieve some information was time-consuming. So to make things easier I threw together a small function that lives in my PowerShell profile. It will return a list of current supported API versions for given resource type (just like the code above). However the main difference is that when I need to query a resource I can just run the following command in my session:

Get-AzureRMResouceTypeAPIVersion -ProviderNamespace "Microsoft.Network" -ResourceTypeName "loadBalancers"

Here is the code:

While the function is nothing special, it demonstrates how building your own tools around existing functionality can speed up your learning and development processes.