Let me first disclaim that my understanding of the situation I describe herein is a little tentative, so feel free to let me know if I am misunderstanding anything.
In our environment we have vCAC 6.1 and vCO 5.5.2. We also installed the Infoblox plug-in in vCO. This installation customized the WFStubBuildingMachine and WFStubMachineDisposing workflow stubs in vCAC to add calls to the Infoblox vCO workflows for IP address management. That's all dandy until you come along and run the Install vCO customization workflow in vCO, which wipes out the customization to the vCAC workflow stubs previously done by the Infoblox plug-in installation.
How do you deal with conflicts such as this? What if another 3rd party plug-in also wants to customize the same vCAC workflow stubs? It seems like a messy approach for plug-in providers to take. I am under the impression that using the vCAC plug-in in vCO to install vCAC workflow stub customizations is now the preferred means of extending vCAC with vCO workflows. It lets you focus your workflow customization efforts in vCO rather than using the clunkier (IMO) vCAC Design Center. What thoughts does VMware and the community have on this? Thanks.
You might want to check with Infoblox (or any vendor), but you should only need to make those customization changes once for vCAC to use vCO rather than the internal stub workflows for different states. I'd venture a guess that it's (probably) running the same workflow.
Hi. I work at Infoblox supporting all technical activities regarding the IPAM plug-in. The next version of the IPAM plug-in will use vCO workflows to get it configured to work with vCAC. There will be no need to use vCAC Designer or deal with XAML files. The entire process to install and configure the IPAM plug-in will be very smooth and will not cause any conflicts with 3rd party plug-ins. Thanks.
To avoid conflicts, we set up our workflow stubs in vCO once, using the vCAC plugin, pointing to blank wrapper workflows. Then, if we wanted to integrate with plugins or custom workflows we'd written, we just called the required workflows from the stubs we set up. This way, all our changes were made by us and we didn't have to worry about conflicts or about a plugin overwriting anything.
So, for our Infoblox integrations, we created a blank stub for BuildingMachine and a stub for MachineDisposing. All the required integration for Infoblox was added in these two workflows, along with our other provisioning/decommissioning tasks.