vRealize Automation lets us publish vRealize Orchestrator workflows to the service catalog, but to get more functionality out of these XaaS blueprints, we can add the provisioned resources to the items list. This allows us to manage the lifecycle of these items and even perform secondary “Day 2 Operations” on these items later.

For the example in this post, we’ll be provisioning an AWS Security group in an existing VPC. For now, just remember that AWS Security groups are not managed by vRA, but with some custom work, this is all about to change.

Prerequisites

If you’re following along at home, ensure that you’ve got the following items available.

• An AWS VPC with already setup
• AWS vRO Plugin Installed
• The AWS vRO Plugin is configured to work with your Amazon Account
• vRealize Automation 7 already installed with basics. For more info, check out my guide.

Add a Custom Resource

Here we need to define a new type that vRA will understand how to manage. To do this go to the Design tab –> XaaS –> Custom Resources. Click the green plus “+” sign to add a new custom resource. Under the resource type, we need to look for an orchestrator type. NOTE: if you don’t have the AWS vRO plugin installed, you won’t be able to find the “AWS:” type listed here. These are objects in vRealize Orchestrator that must exist before you can use them in vRA. I’ve added AWS:EC2SecurityGroup as the Orchestrator type and given it a description.

On the next screen, the option to modify the form will be available, just like with an XaaS Blueprint. Feel free to modify the form however necessary.

Create XaaS Blueprint

Creating an XaaS Blueprint is probably nothing new if you’ve gone through the vRA guide. Lets go to the XaaS Blueprint section and add a new workflow to create a new AWS Security Group. In the workflow tab, find the “Create Security Group” workflow from vRealize Orchestrator. Notice that in the right hand pane, the output is “AWS:EC2SecurityGroup.”

Next, on the “General” tab enter a name for the blueprint and a description.

Again, we’re able to modify the blueprint form format on the next tab.

The last tab is the “Provisioned Resource” tab. Prior to setting up our own custom resource earlier, the only option for this dropdown was “No Provisioning.” Now we have a new resource called “securityGroup.” Be sure to select the new resource here so that vRealize Automation knows that the result from the workflow will be the new custom resource in vRA.

Create a Custom Action

This part is optional if your goal is understanding how custom resources can be provisioned in vRA, but it makes good sense to have an action so that it can be used to remove the security group later on and demonstrate more robust capabilities. Go to the Design Tab –> XaaS –> Resource Actions and click the green plus “+” sign to add a new resource action. In the workflow tab, select the action we will want to be able to perform on our AWS security group. In our case, we select the “Delete Security Group.”

Next select the resource type which will be Security Group, our newly created resource type. The input parameter will be group.

Next give the action a descriptive name as well as a description and version number.

As with the rest of our XaaS blueprints we can modify the form. In this case there is nothing to add to the form.

Publish and Entitle

For each of the blueprints and actions that we’ve built, ensure that they are published. If you need help with publishing catalog items please see the following post for more details.

Next, go to the Administration tab to add the appropriate entitlements.

Don’t forget to add the “Delete Security Group” to the entitled actions. If you need more help with entitlements please see the guide post here.

Provision Custom Item

Lets go and request our item from the blueprint now to see what happen. In the picture below you can see that I have AWS Service and one of my blueprints is “Create Security Group.” I’ll request this blueprint.

Add a description for the request and a reason for the request. Standard practice for any normal XaaS Request.

On the next tab of the request, we select and enter our information to run the vRO workflow. Such as which AWS account to use, the name of the security group and a description for the security group.

The Results

Once the blueprint is requested, the vRealize Orchestrator workflow will run and hopefully create the security group. The screenshot below shows the token where the workflow ran successfully.

If we take a quick peak over at my AWS console, the security group was created with the name and description that I specified in the request.

Here’s the neat part. If you go to the items tab in vRA, we’ll see a new tab called “AWS.” Click that AWS tab.

In the AWS tab, we see a new tab called “Security Group” and in the items list, we see the Security Group that we just added, only now as an item managed by vRealize Automation!

Since we created a resource action, we can click on our new item and we’ll find an action associated with our security group. This action allows us to delete the group.

Summary

vRealize Automation does a great job of managing servers by default, but not all of the things we do with vRA are server related. XaaS allows us to give our end users access to perform a wide variety of tasks that aren’t related to server provisioning. vRA can be extended to allow for other types of objects to be managed through the cloud management portal. Perhaps, adding or disabling AD Users might be another great use case for this extensibility. Can you create those workflows?