Unraveling Your Customizations in vRA7 to Prepare for vRA8

by: Mike Bombard / December, 9 2019

Although you may not be ready to make the move to vRealize Automation 8 just yet, it’s time to start planning. Time to start unraveling all the customizations and integrations that make your vRealize Automation 7 environment perform it’s magic. If you’re like most vRA7 users, it is a combination of third party integrations, open source customizations, home grown customizations, and scripts joined together around your specific business process that makes the automation magic happen.

Many vRA7 environments are grown organically over time, with new integrations and customizations added as the needs arise, and little — if any — documentation on exactly what they are and how they work. So where do you begin? My recommendation is to start at the beginning.

Blueprints

You will first need to take inventory of your blueprints. Documenting which ones overlap and which have differences. Some may have different custom forms with unique logic embedded within. Inputs may vary drastically from one to the next. Understand what those differences are and why they are there. What happens to those inputs after they are submitted? It’s important to break these inputs down into groups so you can save time by understanding which blueprints have shared integrations and which ones have unique integrations.

System Custom Properties

Many of you are very familiar with the vRA Custom Properties Reference. vRA8 does not currently have an equivalent resource that guides you through how to properly use custom properties in the new product, and, from all accounts, it appears that the custom properties used in vRA7 are no longer valid. If you are using any of the VMware defined system custom properties in your environment, you will need to make a determination in the new platform on how to address each of the transforms. Each one of these properties is setting some type of customization for your provisioned resource, and the mechanism for applying similar customizations in the new product is different.

Custom Forms

Although Custom Forms have only been available since vRA 7.4, they were quickly adopted because custom forms allowed many users to solve challenges they were previously unable to address. Your custom forms may have unique business logic included within them. It’s important not to overlook this logic because it may play a very important part in your overall automation outcome. Determine which blueprints have custom forms and thoroughly review each one, documenting any embedded custom logic and what its purpose is.

XaaS Blueprints

Many vRA7 users have adopted the use of XaaS Blueprints before the release of custom forms to allow for a more customized request interface and to accommodate custom business logic into their vRA7 solutions. These XaaS Blueprints can include business logic, integrations that need to run pre-request, and logic to drive outcomes such as which composite blueprint is ultimately requested. XaaS Blueprints can be the most involved part of your assessment.

I’ve seen vastly different adoption of these blueprints from a single Xaas Blueprint that is used as the sole mechanism for making vRA requests to environments with XaaS Blueprints for every different Composite Blueprint in the environment. These XaaS Blueprints often contain custom vRO actions, which makes them even more complex. XaaS Support in vRA8 is very limited, with no support for Resource Mappings, Custom Resources, Dynamic Types, and other features you may be using in vRA7. To migrate to vRA8, you should plan to eliminate your XaaS Blueprints altogether. For more information on what XaaS support in vRealize Automation 8 check out Identifying Important Gaps in Features, Functionality, and Integrations Part 2 of 2.

Day 2 XaaS

You probably created XaaS items to be used as Day 2 actions. This capability currently doesn’t exist in vRA8, so it’s critical to review and understand the importance of these capabilities to your organization. Review all of your Day 2 XaaS functions, and make a note of all the supporting vRO workflows that they utilize.

Event Broker Subscriptions

Next, you will want to review your event broker subscriptions. Don’t look on the surface. These subscriptions may have rules that are used to determine when these events are executed. This understanding is important because not all subscriptions may be used for every deployment. You will need to understand what rules are in place to be able to map these subscriptions to their actual function. As part of this review, you will also need to figure out what workflow is being called as part of the subscription.

vRO Workflows

At this point, things get more complicated. By now you should have a list of all your vRO workflows that will need to be reviewed. As we have discussed in A first look at vRA8 Migration Assessment Tool Part 2 of 2, there are a number of key changes that will require you to significantly rework these workflows or perhaps even recreate them from scratch. Therefore, it’s important to be very thorough when doing this review.

You need to understand what properties are being used in each of your workflows, because these properties are used to drive the behavior of the workflow. In vRA8, not all properties are available at every state. This change is very critical. If the workflow that you are reviewing is executed at a specific state, and needs access to specific information, this information may not be available at the point in time in vRealize Automation 8.

After reviewing the needed properties that are being used, you will need to dig into your workflows to understand a number of items:

Does business logic exist? If so, what is its purpose?
Does the workflow talk to external systems? If so, how?
Does the workflow use the vRA7 plugin?
Is information being written back to vRA? If so what information?

While every situation is unique, and you may have workflows that can be adapted to work with vRA8 with some simple modification, you should strongly consider starting over and recreating these workflows specific to vRA8. Your existing workflows were designed and architected around the vRA7 architecture, which is significantly different than that of vRA8. While things make look like a good idea in principle, they may not work out so well in practice.

How SovLabs can help you start preparing for vRealize Automation 8 today.

We’ve been working with many organizations to start preparing for vRA8 by displacing the aforementioned customizations with out of the box software tools. One by one, we’re removing these items today so you don’t have to re-write, modify, or recreate these items when you are ready to make the move to vRA8.

To learn more about how we can help with your migration to vRA8 and the benefits of moving away from customizations on vRA7 in preparation for vRA8, please attend our upcoming webinar or contact us for a personalized review of how we can help you prepare for what’s coming in vRA8.