VMware Cloud Community

customizing content of ASD based request form field


IHAC that want a ASD workflow in the vRA catalog to add a user to a group in AD. So far so good, but this customer has a multi domain environment and if you search through the ADs you get only the names without the domain information. How can I change the behaviour so that the domain information will be shown in the search results? For example you search for user John and get several users from the the AD with the name John but not the information in which AD/Domain. I need the information in the form as johndoe@example.com or johndoe@master.com. I can´t go with a tree form field it must be a search form field.

Any suggestions?



Tags (1)
2 Replies


Bare with me as I try to explain.

When we are looking for objects in an ASD form, in reality we are looking for the ability to select something that represents an object.

When you work with built-in objects in the form:

1. You are constrained by the capabilities available for working with the objects within the plug-in.

2. It tends to be slow.

What we need is a method to pull a list of what we want to present to the *requestor* that they can then select from (or search into) where the selection of that item becomes a useable object in the backend workflow.  When you use the builtin process, you get back the object and the object is handed into the workflow for your use.  BUT as you have seen, it doesn't do everything that you want (see item 1 above).

There is a programmatic method to get around all of these problems, in any plugin, that allows you to customize ASD forms in a very powerful way.  Once you start down this road, you may find uses for this method in everything you do within ASD.  It only takes the first step...

The simple of it is that you do everything possible to leverage Strings and Arrays of Strings in ALL forms and type convert (find) your object in the backend workflow.  (It is always this pattern.)

1. You can present information in the form in any format you want to parse. E.g. "Sean Kohler (myaccount@mydomain.com)"

2. It tends to be lightning fast.

A few screenshots would be useful to this explanation...

1. Did a lot of testing with AD objects and methods.


2. Here is one model of a manage group form that has a search field, a selector from the search and a working selection representing EITHER the users being added or removed to/from the group.


3. I have an OGNL trick that changes the Action that runs when ADD is selected so I can use the same Working Selection field for users I want to remove from the group and users I want to add into the group... but that isn't necessarily important as you can just have two fields that are alternately hidden based on activity. That everything you see on the page is a string is important.


4. So in the form, I collected a list of strings (that were presented "By AD Host" by the way, and I will get into that momentarily) Strings are not what I need to work with though.  I need objects.  AD:UserGroup, AD:User, etc. So the workflow takes the strings and converts them into what I need first thing.


5. So your question was about multiple domains.  All of the lookup methods in the AD plugin have an ability to supply AD:Host. So you just build actions that take your Strings (in the format you want) and do an AD search for the object.



Use vRO actions to get strings for ASD forms from the places, you want, constrained how you want, and in the format you want.

Use vRO actions to convert the strings (during workflow execution) into objects.

Why? Because... it is flexible... and it is fast.  (try working with Business Groups or lists of CatalogResource objects... and see the enormous speed increase doing string name lists is in comparison to object lists)


So after I had built all those tutorials for myself and my team, I came to an epiphany.  There is actually no reason to need to send in AD:Host to any action either.  By using this action, you can lookup an AD:Host inside another action based on a String input of the AD:Host name.  Why is this important?  Because this way you can call AD searches BY AD HOST right from ASD external Actions.

So for example, create an action that returns a string array of users based on a search term but also takes a string AD:Host.

When you call the action... e.g.

stringArray = System.getModule("org.myaction").getUsersByAdHost(stringSearchTerm, stringADHostName)

...it has within it the call to the below action and gets the host you need, searches using the search term from that host... and gives back the correct list of users from the correct domain.


Here is a specific example of how I use the above.  If I call this from an ASD form field, I can just supply the data from the search field and a domain name selector.

(I cannot share this script in full, but it is very useful... recursively pulls an array of Users from a group while handling the potential for cross group nesting)


I hope this helps you in ASD in general, more than just getting appropriate results in a multi-domain environment.


Hi Sean,

Your answer is very helpful, thanks for that. My hope was that there is an easy way ... maybe a workflow package ... but now I have the hints to build my own package.

Thanks Olaf

0 Kudos