With vRealize Automation you can connect to different vRealize Orchestrator servers for handling your workflow stubs. Just add more vCenter Orchestrator endpoints or configure a vRO load balancing cluster. But what if you want to configure a location specific vRO server?
The custom property VMware.VCenterOrchestrator.EndpointName will help you here. With VMware.VCenterOrchestrator.EndpointName you can link a specific vRO endpoint to a compute resource, reservation, business group, property dictionary or blueprint. For a location specific vRO I would recommend to set this custom property on a compute resource or reservation level. In this way the specified vRO server is used when a blueprint is deployed to a particular compute resource/reservation. Note that a VMware.VCenterOrchestrator.EndpointName setting on business group, property dictionairy or blueprint level overwrites the value on computer resource/reservation level.
Some background info
If you’re using the vRealize Automation vRO plugin, the WFStub workflows in vRO (located in Cloud Automation Center/Infrastructure Administration/Extensibility/Workflow stubs folder) act as workflow runners for vRA. These workflow runners are called directly from vRA based on the vRO workflow ID. Because the workflow IDs of these helper workflow are the same for each vRO environment, it’s no problem to change the vRO server for a specific location; workflow runners with exactly the same ID are used.
The workflow runners at their turn start the requested (and by the user configured) vRO workflow using the workflow ID in the custom property ExternalWFStubs.Buildingmachine/MachineDisposing/MachineExpired/MachineProvisioned. This ID will be unique for each vRO server; at the end blueprints at location A will use other vRO workflows then blueprints at location B.
Hope this was helpful, you can leave your comments and feedback below.
