Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
In Part 1 of this two-part series on the vRealize Automation Migration Assessment Tool, we looked at the vRA8 migration tool to see how it might help you plan your migration from vRA7 to vRA8. In this article, we are going to look at what it will take to migrate your custom workflows from vRA7 to vRA8. To start, we will explore what a custom workflow looks like to day in vRA7.
SIGN UP FOR THE VRA8 BLOG SERIES & WEBINAR
vRA7 Workflow Components
In vRA7, there are a number of components that come together to make the magic happen. Each component plays a vital role in how you design, build, and invoke your customizations.
Event Broker
The event broker was introduced in vRA7 to make it easier to trigger the workflow stubs that existed within the IaaS server. These stubs were always there, but only a handful were accessible and they were not easy to configure. The Event Broker also introduced a more granular way to decide when a workflow should or should not be executed. Although the event broker has dozens of events you could subscribe to the following were the most commonly used:
- Machine Requested
- Building Machine
- Machine Provisioned
- Machine Activated
- Machine Destroyed
Many of these states included a pre and a post execution allowing you to decide if you wanted to execute your workflow before of after vRA’s execution of that state. These states that are the core of vRA7 extensibility no longer exist in vRA8. vRA8 is a completely new platform, written from the ground up, and no longer includes the IaaS host that controlled all of these states in vRA7.