Update 29/09/2016:
The API documentation for importing a vRA Content Package contains a warning:
At this point, we don’t support any form of rollback strategies. A failed import may potentially leave the system in an inconsistent state. Hence, its highly recommend to run a precheck/dry-run before the import to validate the package. See HTTP POST /api/packages/validate for more details. This will help catch most of the errors upfront.
Consequently, in release 1.
One thing that I know colleagues and others are keen to automate with PowerShell and vRO is exporting and importing vRO packages. If you’re not familiar with a vRO package it is typically used to bundle up all of the Workflows / Actions / Configuration Elements / Resource Elements which make up the code for a particular project and use the package to transport the code to another system. So you may for instance wish to export a package and copy it to another vRO server or maybe into a version control system, or you may wish to automate the deployment of vRO itself and include importing the code as a final step.
Aside from any documentation around your vRO workflows, one of the best ways to quickly get up-to-speed with what it does and visualise how it is put together is to look at the schema. Wouldn’t it be handy if you could easily get hold of an image of the schema for one or multiple workflows? Well with PowervRO and your PowerShell console you can!
The REST API supports this, so we have included a function Export-vROWorkflowSchema .
There are a number of different ways to get your developed vRO content from one system to another: exporting / importing single items, exporting / importing vRO Packages containing multiple items, synchronising content directly between vRO systems.
In this example I’ll show you how to use PowervRO to export and import workflows from and to vRO.
Export vRO Workflows
To export a single workflow is pretty straightforward with the function Export-vROWorkflow:
In the previous episode we looked at how to invoke a vRO workflow with PowerShell, via PowervRO and the Invoke-vROWorkflow function. Once you have kicked the workflow off you are likely to then want to find out the state of the workflow, when it has finished and any output from the workflow. Here’s how to do this via PowervRO.
Check the Workflow State:
First of all, we need to identify which execution of a particular workflow we want to check the state of.
For the PowerCLI book 2nd Edition I helped put together a chapter on vRealize Orchestrator. Most of the chapter was focused on running PowerShell scripts from vRO, which was something I’d had a fair bit of experience with in projects I had been on and also thought would be what most people reading would be interested in. At the end of the chapter I added a few functions using the vRO REST API to run things in vRO from PowerShell as a bit of an after-thought.
One of the things we did for the 1.2.2 release of PowervRA was to test all of the functions against a vRA 6.2.4 deployment. Now that we have created Pester tests for all of the functions, it is quite straightforward for us to test against different vRA versions.
While we had initially targeted vRA 7+ because of the better API support, we know that currently the majority of installations out there are 6.
Learning Pester has been on my list to get done this year and while working on PowervRA I finally had a real project that could make significant use of it. Being able to automate the testing of each PowerShell function means that we can quickly test the impact of any changes to a function. Also, it means that we can test the whole module full of functions against new (and potentially old) versions of vRA.
One of the reasons behind creating PowervRA was as a consultant I often have the need to quickly spin up vRA Tenants and / or components within those Tenants to facilitate development or testing work of other things I am automating. PowervRA contains three functions, which when joined together would make a basic vRA Tenant available for use: New-vRATenant, New-vRATenantDirectory and Add-vRAPrincipalToTenantRole.
The following code example demonstrates how to use these in conjunction with each other to make a vRA Tenant (make sure to first of all have generated an API token with Connect-vRAServer with an account that has permission to create a vRA Tenant):
A colleague asked me the other day about how it might be possible to find out which vRO workflow was mapped to an Advanced Service Blueprint (or XaaS Blueprint) in vRA. If you look in the vRA GUI after a Service Blueprint has been created you can’t see which vRO workflow is mapped.
During the creation of the Service Blueprint there is a Workflow tab to select the vRO Workflow: