I like the new Swagger UI for the vRO API, it makes it really easy to use:
While using it to figure out some stuff around importing a package, I hit an issue with the tagImportMode parameter:
Depending on which option selected, the following additions to the URL were listed in the documentation as follows:
https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Do%20not%20import%20tags.**
https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Import%20tags%20and%20overwrite%20existing%20values.**
https://vroserver.fqdn:8281/vco/api/packages?overwrite=false&importConfigurationAttributeValues=true**&tagImportMode=Import%20tags%20but%20preserve%20existing%20values.**
However, none of these choices seemed to work, just resulted in 400 (Bad request).
vRO 7.0.1 in Design mode contains a new toolbar button in Packages; Import package from folder:
Previously it was possible to export a vRO package to either a zip file or directly to a folder, but only import back from a zip file.
Exported to a folder test, we get the following:
Now in a clean vRO server, I currently do not have those workflows:
If I select the Import Package from folder button, I can browse to the folder contained the previously exported to a folder package:
The vRO Action requestCatalogItem in the com.vmware.library.vcaccafe.request folder can be used to programmatically request an item from a vRA Catalog.
One of the inputs is a properties object which permits you to dynamically make changes to settings configured within the Catalog Item you are deploying from. So say for instance the Catalog Item maps to a Blueprint configured with 1 vCPU, you could change this at request time to be 2 vCPU - which for instance might lead you to needing to maintain fewer Catalog Items.
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:
Part of the wizard to setup vRA 7 includes a step towards the end to create a vRO workflow that will create initial content within a vRA Tenant. To run the workflow, login to the default vRA tenant as the configurationadmin account created as part of the initial setup:
There are various inputs required depending on such things as if you wish to use the default Tenant or create an additional one:
A significant pain point on a recent project of mine was automating the creation of blueprints in vRA 6.2 with vRO. There was very little information around on how this could be achieved and even with the method that we eventually came up with still required some manual effort and was not always the most reliable.
Enter vRA 7 and some hope that things may have gotten better.
First of all I looked through the vRA 7 Programming Guide and found some examples on exporting content from vRA 7.
I’ve been looking for a decent learning resource for vRO since I started working with it and finally got some time to get through the VMware vRealize Orchestrator Cookbook by Daniel Langenhan. I spent most of my early days with vRO just trying to figure out how to do things and why some things worked in a particular way - and mostly haranguing Michael Poore for some answers :-)
This book covers getting everything setup and various decisions to be made about the design of the infrastructure pieces needed; Windows vs Appliance, which database, clustering etc.
When editing a vRealize Orchestrator workflow there’s a default option in the client which prompts you to increase the version of the workflow when you select Save and Close.
While this is intended to be a good idea, since it at least makes people think about version control in their workflows and consequently they are then able to take advantage of some of vRO’s versioning features, it contains a fundamental flaw and makes me cringe when I see someone use it…
vRA Build 6.2.2-2754020
vRO 6.0.1
Via the vRA GUI I can create Business Groups with the same names in different Tenants as follows:
Tenant1: BusGroup1, BusGroup2, BusGroup3
Tenant2: BusGroup1, BusGroup2, BusGroup3
However, creating the Business Groups with the same names in different Tenants via the vRO plugin, specifically the workflow Library / vCloud Automation Center / Administration / Business Groups / Create a Business Group, fails in the second tenant with the below error:
Querying vRO workflows using the vRO REST API is relatively straightforward task. Use the below URL with a GET request and specify a condition to search for them, e.g. to find one by it’s name use:
https://vroserver.domain.local:8281/vco/api/workflows?conditions=name=test01
You should get a response similar to the following if a workflow of that name exists:
[javascript]
{ “link”: [ { “attributes”: [ { “value”: “https://vroserver.domain.local:8281/vco/api/workflows/cb9264b1-c832-4ee3-b95a-db73f7a2fedf/", “name”: “itemHref” }, { “value”: “cb9264b1-c832-4ee3-b95a-db73f7a2fedf”, “name”: “id” }, { “value”: “Test”, “name”: “categoryName” }, { “value”: “true”, “name”: “canExecute” }, { “value”: “https://vroserver.