I recently wrote the Leverage vRealize Automation’s Action Based eXtensibility (ABX), Event Broker Service (EBS) & APIs for Email customized notifications blog, we took advantage of Action-based extensibility ( ABX ), which  provides a lightweight and flexible run-time engine interface where you can define small scriptable actions and configure them to initiate when events specified in extensibility subscriptions occur.  You can even create these extensibility action scripts of code within vRealize Automation 8 and Cloud, or on your local environment, and assign them to subscriptions.

However when we wanted to re-use this ABX action among our existing vRealize Automation 8 and Cloud‘s Projects, we couldn’t do it unless we cloned the ABX Actions as many times as many Projects we wished to execute the customized functionality, this obviously increases the operation overhead and makes content management a daunting task.

So here’s the good news, vRealize Automation 8.2 and Cloud has recently introduced the ability to create extensibility actions that can be shared across projects without exporting and importing the action, furthermore these ABX actions can be executed in different FaaS providers as per Project assignment.

Let’s see the Shared Action-Based Extensibility in…well “Action” ( no pun intended )

I defined a couple of Projects, Project A has only one single AWS based Cloud Zone and Project B, similarly, it has one single Cloud zone but for MS Azure, then I created an specific Cloud Templates for each Project ( Ok no points for creativity ), then I produced a new ABX Action that I named “Team Feedback” with a default association to Project A.

 

Create ABX Action

 

Kindly note the new check box available, “Share with all projects in this organization“, so I can use it with Project B ( and any other Project in the Organization if needed ), of course, you can change this behavior at any time, just keep in mind that this setting can not be changed if the action is shared and used in a subscription with any project scope.

I then crafted I small Python Script that takes as input the Resource Names and  the Project Name, it sends a Slack Notification with that information, FaaS Provider is set to “Auto Select” and finally I versioned and released the Action, because it is good practice but also I want my customer to consume this ABX Action from the Service Broker Catalog ( more later ).

At this point all I need is to define a subscription that can make use of my ABX Action, so I dubbed the new Subscription, “My Project A and B”, I decided to use the “Compute allocation” event topic, as it provides the input I need for my script, no conditions necessary and I mapped the Subscription to my previously created “Team Feedback”  ABX Action.

Now, in terms of Subscription Scope, I have the option to toggle on “Any Project” , which essentially subscribes this ABX Action to all my projects in my Organization, however I also have the ability to hand-pick the specific Projects and we don’t want to disturb any other projects with my development..true story,  having said that, I will select Project A and Project B, so I keep toggle off for “Any Project” , I click on ADD PROJECTS and will pick from the list, Project A and Project B only

 

Add Project

 

after that,  the only task left is to save it, please note the Scope indicating 2 Projects.

 

Subscription Details

 

Let’s go ahead and Deploy Cloud Templates for both Projects A and B

 

Deployment Project A and B

 

When looking at the “Action Runs” activity, we see two new events :

 

Shared ABX run

 

 

If you look closely, you can tell the name of the Action is the same, “Team Feedback” as well as the version “3” and that they were triggered due to an Event ( our Subscription to the Compute allocation ), but most importantly, you can see that two different Projects, the ones we defined in our subscription, A and B, were able to use | share the same ABX Action, furthermore, both Projects executed the ABX Action at their available or preferred “FaaS Provider” by their Cloud Zone assignment, this is the message that was sent to Slack:

 

Slack Notification

 

Some lines above, I said I wanted my customers to consume this ABX Action from the Service Broker Catalog as well, for that, since I have already versioned and released my ABX Action, I will move into the Service Broker, and under Content Sources, I created two new sources corresponding to each Project with the type set to “Extensibility actions“,  I also selected and added the “Team Feedback” item for Project A, after all the ABX action has a default Project assignment which in this case it is Project A, note that when I select Project B, Content Sharing actually includes the Shared Content with Project A.

Content Sharing

 

We’re all set and we can go to the Service Broker Catalog and discover that there is a new Catalog Item named “Team Feedback” and available to both Projects A and B

 

Catalog Project A and B

 

Let’s go ahead and request it for Project A and Project B, please note the Project field will expose a pull-down menu with both options

 

Request A

Request B

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

After I submit the requests, they got fulfilled ( note the resource type Action )

 

Deployment Action

 

And when inspecting the “Action Runs” activity, we see two new events :

Action Run SB

 

 

Once again you can see that the name of the ABX Action executed is the same for both Projects, “Team Feedback” but  this time they were requested by the Service Broker via the API,  beyond that, you can verify that Project A and B ( as per our request ), were able to use | share the same ABX Action, leveraging their available or preferred “FaaS Provider” by their Cloud Zone assignment, here’s the feedback notification received at Slack:

 

Slack ABX SB

 

Conclusion

As a vRealize Automation Administrator having now the ability to re-use your ABX actions without exporting and importing then assign them to multiple Projects as needed or to the whole Organization, not only streamlines the reusability of our actions but makes the system simpler to operate and reduces the overhead for Content Management and dependencies.

For more information feel free to check these blogs out:

Self-Service Hybrid Cloud – Part 2 – Using vRealize Automation ABX to make API calls to VMware Cloud on AWS

vRealize Automation Action Based Extensibility (ABX) now supports PowerShell

Leverage vRealize Automation’s Action Based eXtensibility (ABX), Event Broker Service (EBS) & APIs for Email customized notifications

HOW-TO: ABX/vRO Powershell actions which include additional Modules