vRealize Automation - Workflow Stubs explained

There appears to be a little haziness when talking about stubs, integration and vRO (formerly vCO) workflows. There is a number of blogs and articles all over the web about this, and I figured it's about time I write another article to help explain this - at least the way I see it.

First off, let's take note of the Architecture of vRA (formerly vCAC) as of version 6.2:

Looking at the image above, vRealize Orchestrator (formerly vCO) features in the architecture as a default.
Also, very importantly, the DEMs run on Windows x86 and do actually run their own Microsoft .NET workflows (a.k.a XAML a.k.a WWF) - these are not vRO (vCO) workflows. 
In fact, prior to vRA, the previous iterations of this product were based entirely on Windows  / .NET.

Now, let's bear this mind and move forward. These .NET / Microsoft / XAML workflows are architected in a way that allows us to plug in additional workflows by injection at various states.
The Master Workflow related to Virtual Machines (for the purpose of this article) looks something like this (there are more states, but we're only interested in these for now):

Note that the start point in this diagram is Awaiting Approval. Using advanced configurations, Repository uploads and some XML files in a certain folder, we are actually able to hook in to any one of these states above and inject our own custom workflows. Since this particular feature is beyond the scope of this article, I will be showing you, instead, what the stubs are all about.

We will focus primarily on these items for this article:

At each of the above states, the .NET architecture provides stubs. These stubs are empty at initial install, but still provide a hook to do stuff. See below:

Now, each of these stubs are, in fact, Microsoft .NET Workflows, already present, in XAML format. Let's assume for a moment that we wanted to do something at the Building State. We would simply open up the WFStubBuildingMachine XAML file, add an activity and save it. Done.

However, this would typically require knowledge at another level - the details of which are beyond the scope of this article. There is, however, an easy way to leverage these states.

Enter vRO (vCO)

Imagine we could simply tell each of these stubs: "Execute this particular vRO Workflow".

This is exactly what the integration with vCO does.

This process is explained in detail in an earlier post on this blog site here.

I hope this has helped to clarify just a little, what these stubs are and how they function.

Keep on keeping on.