In this post I will talk about the Aria Automation Orchestrator (AAO) folder structure I propose to customers whenever I start an engagement including AAO.  The basic structure and why I use it.

I have developed this based on lessons learnt by me and other consultants on large enterprise engagements.  Lets call this a default practice I use, in the absence of more stringent customer requirements, practices, frameworks or use cases which dictate an alternate structure. I hope by sharing it you won't hit the issues I did.

Note: This article will only touch on Workflows and not Actions, Config Elements or Resource Elements.

Essentially the top level workflow folder structure I use looks like this

Library

This is the default Library folder, the contents are vast and come preinstalled out of the box.

As a rule I try to never add, modify or delete anything in this folder (it is locked so modifying and deleting is not easy to do anyway).  This is because the contents of this folder will be updated and modified as Orchestrator is updated, or upgraded.  I think it is good to know that everything in this folder was supplied and written by VMware or Vendor Partners, almost guaranteeing the code is good and the workflows are working.

Library - Custom

I create this folder, it is the library the customer and I publish workflows to.  Anything we have developed, completed and tested.  These workflows are ready to be used in production.

Directly Called by VAA  (VAA is currently the Acronym I'm using for VMware Aria Automation, until there is an official shortening.)

In this folder I keep anything that is called directly from AAO either by extensibility subscription, resource action or catalog item.  Even if I am just going to call a workflow from the library I will create a wrapper workflow here and pass it through to the library workflow.

I do this for good reasons:

1. The ability to trace the impact of changes.  If you want to change a workflow in AAO and you are not sure what you are going to affect, you have the ability to find dependencies.  However this will not find dependencies in VAA only AAO.  By having workflows dedicated to anything being called in VAA it is then possible to trace dependencies to those workflows making it apparent when your changes will affect VAA.
2. Event subscription tracking. When I setup event subscriptions that call AAO workflows, I also usually try and group them in type and then order of operation, this way you can see what is likely to be triggered at each stage.
3. Its just visually nicer and quicker to find. Simples.

Example

zzDevelopment

You could call this just Development, or Scratch, or Working Area. I like zz at the start so its at the bottom of the tree.  This is where workflows are developed until the get used in prod.

I suggest that under here you create a folder for each user who is developing workflows based on their username.  I also suggest all workflows in all these folders is prefixed DEV to make sure everyone knows.  This is especially useful when you try and search for a workflow but there are two and you don't know which is in the Dev folder and which one the library folder.

Please, Please, Please move your workflows before you use them in a production situation, too many times I see work in dev folders in the dependencies list of production workflows.  No use having them in development if they are production workflows, it just muddies the water.

Summary

This is a pretty easy structure to follow and saves you trying to retofit something later.  If your just getting started I suggest this is a great starting point for structure.  

Was this helpful? Do you use something similar?  Do you have some improvements or alternate structure ideas?

Reach out, either through the comments, or connect with my in LinkedIn and we can discuss it there.  LinkedIn connection is on the about me page. I would love to hear from you.