In this blog post we are going to look at how to handle multiple vRealize Orchestrator servers as integration in Cloud Assembly, Code Stream and Service Broker.

• Introduction
• Running a WF as part of Extensibility in Assembly
• Running a Pipeline with WF’s coming from CodeStream vRO Endpoints
• Running WF coming from Assembly vRO Integration in Service Broker
• Running WF coming from Code Stream vRO Endpoint in Service Broker
• Final Step

 

Update Log:

Introduction

Before we continue special thanks to my college and frien Ivo Gaydajiev for the help to figure all this out

Cloud Assembly supports the integration of multiple vRealize Orchestrator servers that can be used not only in workflow subscriptions, but an enable workflows (WF) to be exposed in Service Broker. We are going to see how we can manage where a WF will be executed when we have more than one vRO integration.
Consider an example use case for this as follows:
– You have 2 vCenter cloud accounts in Assembly: vCenter A, vCenter B
– You have 2 vRO integrations in Assembly: vRO A, vRO B
– Each vCenter is paired with vRO in a different GEO.
– You build a blueprint that can deploy on both cloud accounts.
– You have WF A in vRO A and WF B in vRO B. This is exactly the same WF. It is exported/imported between vRO’s
– You want to trigger a WF in a different vRO depending on where you are provisioning as part of your extensibility.

We are going to discuss few places where vRO WF’s are being used and how to affect where the vRO will be provisioned:
– Assembly: Running a WF as part of Extensibility
– Code Stream: Pipelines with WF’s coming from CodeStream vRO Endpoints.
– Service Broker: WF’s coming from Assembly vRO integrations
– Service Broker: WF’s coming from CodeStream pipelines / CodeStream vRO Endpoints.

Running a WF as part of Extensibility in Assembly

First lets look at the setup I have.
I have 2 vRO integrations added in Assembly: vRO A and vRO B

As you can notice I have placed and ID capability tag to identify each of them: cas.integrations.id:vro_a and cas.integrations.id:vro_b
In both vRO instances I have the same WF: WF A

I have two vCenter cloud accounts: vCenter A (vCenter on-prem) and vCenter B (VMC Cloud)

I’ve created an Extensibility subscription and selected the WF for it.

As you can notice when I have selected the WF it noted that there are 2 integrations where this WF is available.
On a Project level I haven’t selected any extensibility constraints.

Now lets see what happens if we deploy a BP and expose few use cases.

CA-UC1

Setup:
– Project: No constraints
– Integration: No constraints
– vCenter: No constraints
– WF: present on all vRO’s

Outcome:
– Extensibility will trigger WF A in either vRO A or vRO B (based on round robin), regardless if we deploy on vCenter A or vCenter B

CA-UC2

Setup:
– Project: No constraints
– Integration: No constraints
– vCenter: No constraints
– WF: present on one of the vRO’s

Outcome:
– Extensibility will trigger WF A in either vRO A or vRO B (based on round robin), regardless if we deploy on vCenter A or vCenter B
– If Extensibility chooses vRO A it will succeed.
– If Extensibility chooses vRO B it will fail.

CA-UC3

Setup:
– Project: Constraint Tag – cas.integartions.id:vro_a
– Integration: Constraint Tag – cas.integartions.id:vro_a
– vCenter: No constraints
– WF: present on all vRO’s

Outcome:
– Extensibility will trigger WF A in on vRO A, regardless if we deploy on vCenter A or vCenter B. This is due to the constraint tag we’ve put on a project level.

CA-UC4

Setup:
– Project: No constraints
– Integration: Constraint Tag – cas.integartions.id:vro_a for vRO A and cas.integartions.id:vro_b for vRO B
– vCenter: Constraint Tag – cas.integartions.id:vro_a for vCenter A and cas.integartions.id:vro_b for vCenter B
– WF: present on all vRO’s

Outcome:
– If we deploy on vCenter A , extensibility will try to trigger the WF on vRO A. If not possible it will fall back to vRO B.
– If we deploy on vCenter B , extensibility will try to trigger the WF on vRO B. If not possible it will fall back to vRO A.

In this case the engine turning the constraints in a cloud account to a soft constraints and is trying to match these with a corresponding vRO integration. Because these are soft constraints if the preferred vRO Integration is not available it will fall back to the other vRO integrations

CA-UC5

Setup:
– Project: Constraint Tag – cas.integartions.id:vro_a
– Integration: Constraint Tag – cas.integartions.id:vro_a for vRO A and cas.integartions.id:vro_b for vRO B
– vCenter: Constraint Tag – cas.integartions.id:vro_a for vCenter A and cas.integartions.id:vro_b for vCenter B
– WF: present on all vRO’s

Outcome:
– If we deploy on vCenter A , extensibility will try to trigger the WF on vRO A. it will not fall back to vRO B.
– If we deploy on vCenter B , extensibility will try to trigger the WF on vRO A. If will not fall back to vRO B.
In this case the engine is again turning the constraints in a cloud account to a soft constraints and is trying to match these with a corresponding vRO integration. Because these are soft constraints if the preferred vRO Integration is not available it will fall back to the other vRO integrations. In this case should as we have specified a constraint vRO A on a project level, and constraints on a project level are hard constraints, engine will always trigger the WF on vRO A , regardless in which vCenter we deploy.

 

Running a Pipeline with WF’s coming from CodeStream vRO Endpoints

First lets look at the setup I have.
I have both vRO A and vRO B added in CodeStream.

Now this example is easy. When I create a Pipeline and add the vRO task I have to select on which vRO endpoint to run the WF. Regardless that both of these are connected to the same project, non of the previously explained options will interfere with the CodeStream pipeline deployment.

Running WF coming from Assembly vRO Integration in Service Broker

When you configure a vRO Content Source in assembly you have to add the WF’s that will be imported into the Service Broker catalog. Although you will see the WF A coming from both vRO A and vRO B , you can import it only once.

It makes no difference if you import the one from vRO A or vRO B. it will still work as explain below.
Now let’s see what happens if we deploy the workflow catalog item from Service Broker .

SB-CA-UC1

Setup:
– Project: No constraints
– WF: present on all vRO’s

Outcome:
– Service Broker will trigger WF A in either vRO A or vRO B (based on round robin), regardless which WF is imported in the catalog

SB-CA-UC2

Setup:
– Project: No constraint.
– Integration: No constraint.
– WF: present only on one vRO’s

Outcome:
– Service Broker will trigger WF A in either vRO, regardless which WF is imported in the catalog
– Service Broker will trigger WF A in either vRO A or vRO B (based on round robin), regardless which WF is imported in the catalog
– If Service Broker chooses vRO A it will succeed.
– If Service Broker chooses vRO B it will fail.

SB-CA-UC3

Setup:
– Project: Constraint Tag – cas.integartions.id:vro_a
– Integration: Constraint Tag – cas.integartions.id:vro_a for vRO A and cas.integartions.id:vro_b for vRO B
– WF: present on all vRO’s

Outcome:
– Service Broker will trigger WF A in either vRO, regardless which WF is imported in the catalog

Running WF coming from Code Stream vRO Endpoint in Service Broker

Let’s first go back to Code Stream.
I have a pipeline there that has a vRO Task and that task points to vRO A to trigger WF A

The same wey we have configured the vRO Content Source in the previous chapter, we need to configure a Code Stream Content Source.
Now if I deploy this from Service Broker it will always go to vRO A, regardless of any project extensibility or vRO integration endpoint constraints. It will go in vRO A because in my pipeline it is pointing to vRO A.

 

 

Final Step

If all went well, go grab a beer.