d-fens GmbH

Yesterday I opened a Service Request at VMware because I had problems registering a vCAC host within vCO. The error (again) was related to SSL certifcate issues and that the vCO server (or its Java engine, to be more precise) would not want to accept the certificate from the vCAC host. So when I called I hoped to get a hint on how to circumvent it. However, I got a whole new plugin that should fix the problems – according to VMware support. Later, after installing the plugin I realised it was a little bit more than just the SSL issue they “fixed” …

First you will notice there are more (sub-)folders in the workflows pane of vCO. One of them is called “Extensibility”. This goes well with the new “naming convention” they use at vcacteam.info (Why Your Understanding of the vCAC Development Kit (CDK) is Holding You Back). Meaning, we do not “customise” any more but only “extend” the vCAC product (where you can still mess up a lot with it) …

This is a quite impressive gain in functionality – especially when you notice that the plugin still has the version number 5.1 and only an incremented build version (#338). I would say now the plugin really starts to become usable…

But event better is the stub integration: You no longer have to write your own vCO stub workflows and connect to them from within vCAC Designer. There is a “installation” workflow that does it for you automatically!

but be careful with that: It will replace any existing version of your workflows with its own version, so all you “customisations” (oh, I meant “extensions”) are gone and you have to reinsert them:

Here you will see that you no longer have to pass in a lot of variables. The machine id is sufficient as you now can easily grab any properties from within vCO.
And as an additional drawback: the connected workflows are the ones that come along with the plugin. That means you cannot change them. So you either have to make a copy to edit them. So you better use the new functionality to attach a workflow directly to a (or more) blueprint:

There is some problem with it however, you always have to define to which blueprints to attach. There is no “ALL” switch. So if you really want to fire all WF for all blueprints you either still have to make a copy or attach a second vCO to the vCAC stub in the designer.

A look at the helper workflows and actions is also worthy. There you will find a lot of useful functionality:

You will notice that they all just wrap the ODATA REST interface from the vCAC repository – and even hardcoded the name of the service …

The good thing here is, that you now can access the whole management context (ie repository/management model) from within vCO.

And a final note on debugging “capabilities”: you can now use an action called “logEntityDetails” that you can use to log information about an entity in a MsgBox style to the server log. Now this is what I call great debugging support…

Seriously: if you really want to know about vCAC entities you might probably use LINQpad first and then investigate further with PowerShell (as the vCO plugin is rather a wrapper around it).

All in all I would say this is a really useful enhancement to the product. However with all the lack of developer experience within vCO I still stick to PowerShell scripting (from within vCO or not) as with that I am still magnitudes faster (especially when using the ‘mgmtContext’ directly) …