RonPSSC
Enthusiast
Enthusiast

How to bind multiple vCO workflows to one vcac state change worklfow?

Jump to solution

I'd like to be able to bind more than 1 customized vCO worklflow to the ExternalWFStubs.BuildingMachine State Change but vCAC won't allow me to do this (Indicates the State Change Workflow Name is already in use which therefore prevents me from adding another Value to this Custom Property at the Blueprint Level).

Is this possible? I have 2 separate custom workflows that perform different actions required to be executed during the building state change; 1 creates a new DNS entry while the other creates a new Computer Object in AD. For the record, I also have another vCO customized workflow that is executed during the ExternalWFStubs.MachineProvisioned State Change, so this is not an option either.

Do I need to combine all the Actions in one customized vCO workflow and then associate this workflow with the Machine Building State Change (Stub)WF...???

Thanks. Ron

Update

I answered part of my own question. Combining all the workflows into 1 customized vCO will do the trick. I would still like to know however if there is an easier way to achieve this by (perhaps) associating multiple vCO Workflows to the same ExternalWF Stub..??

Thanks. Ron

1 Solution

Accepted Solutions
JamesMW
Enthusiast
Enthusiast

For what its worth, I just have one "root" workflow for each stub (buildingmachine, disposing, machineprovisioned, etc) that will then kick off any number of subsequent workflows. I find this method easier to track what workflows are running. You also have the advantage of running things asynchronously if they are launched from the same root workflow.


Lastly, you can control the order in which workflows run, and can get creative in when they run. Consider the example:

test.jpg

The code in the 'Do i run this? ' decision could be:

return (updatedProperties.keys.indexOf("RunWorkflow1") > -1);

and 'Run workflow code 2?' was:

return (updatedProperties.keys.indexOf("RunWorkflow2") > -1);

Now, if i add the custom property 'RunWorkflow1' to a blueprint / build profiles / custom property, it will execute 'Run Workflow 1", then skip over the second one and complete. Similarly if you want to run workflow 2, just add another custom property RunWorkflow2 to the blueprint.

If you design this way, it allows you manage 1 root workflow while still customizing blueprints to do different actions.

Hope this helps,

James

View solution in original post

5 Replies
JamesMW
Enthusiast
Enthusiast

For what its worth, I just have one "root" workflow for each stub (buildingmachine, disposing, machineprovisioned, etc) that will then kick off any number of subsequent workflows. I find this method easier to track what workflows are running. You also have the advantage of running things asynchronously if they are launched from the same root workflow.


Lastly, you can control the order in which workflows run, and can get creative in when they run. Consider the example:

test.jpg

The code in the 'Do i run this? ' decision could be:

return (updatedProperties.keys.indexOf("RunWorkflow1") > -1);

and 'Run workflow code 2?' was:

return (updatedProperties.keys.indexOf("RunWorkflow2") > -1);

Now, if i add the custom property 'RunWorkflow1' to a blueprint / build profiles / custom property, it will execute 'Run Workflow 1", then skip over the second one and complete. Similarly if you want to run workflow 2, just add another custom property RunWorkflow2 to the blueprint.

If you design this way, it allows you manage 1 root workflow while still customizing blueprints to do different actions.

Hope this helps,

James

View solution in original post

RonPSSC
Enthusiast
Enthusiast

Hi James;

Sincerely appreciate your input. Your logic and concepts are very sound and your suggestion does appear to satisfy my requirements. Unfortunately though my lack of expertise has placed me in a somewhat disadvantaged position. I seem to be missing some key elements, in particular, the manner in which the Custom Decisions flow from one to another. Any possibility I could get a copy of your "root" workflow so I can validate how you orchestrated all of this? Feel free to sanitize as required?

Thx again. Ron

0 Kudos
JamesMW
Enthusiast
Enthusiast

No worries, glad to help.

I cannot share my workflows, but here is a simple example to get you going.

I duplicated the workflow: Library -> vCloud Automation Center -> Infrastructure Administration -> Extensibility -> Workflow Template. This is a blank template to use when launching vCO workflows from vRA.

I commented the decisions to describe what im doing, let me know if you have any questions.

RonPSSC
Enthusiast
Enthusiast

This is great, James. I'll test in my environment. Should be relatively easy to implement now. Thx for your understanding, patience and willingness to help..!!

Ron

0 Kudos
BaluVirigineni
Enthusiast
Enthusiast

Hi James,

I have downloaded the example workflow and modified it to my current Environment, I have attached the workflow at "Machine Disposing State" and attached Customproperties with Workflow Names to Blueprint; When I dispose a VM deployed using vCAC Worflow is failing with error " Error executing vCenter Orchestrator Workflow: Reference Error: "updated properties" is not defined.

Not sure why it is giving error as "Updated Properties not defined" even though I Created Custom Property with Workflow Names to the Blueprint; Could you check the same and let me know your suggestions on the same.

0 Kudos