vCAC XaaS: Requester Details

The next couple of posts will be more focused about some nice vCAC XaaS things i’ve been doing lately. This post is probably a good way to get to know some XaaS tips & tricks.
When you create an ASD Service – e.g – XaaS / Day 2 Operation, you can get some of requester details , which are handed to you by the ASD/XaaS engine. This comes in VERY handy.

How can this be used? Well, for an example, if you build a catalog item that grants the user with a Virtual Desktop, meaning, a Desktop-as-a-Service , you will be able to determine who you need to entitle the new desktop for – seamlessly.
No need to query the user for their details (user name, department ) you might just want to query what the desktop is used for and why , and that’s itץ Advanced Service Designer will automatically fill the gaps for you.

The information that is retrievable is:
– By whom the Request was made
– Who was the item/day 2 requested for (in case of an ‘On behalf of’ request
– Tenant reference (which in vCAC is the tenant name)
– Subtenant reference – The business group uuid
– The catalog request id
– Any static parameter that was inserted in the ASD form.

In order to get these essential parameters, all we have to do is to build our Day 2 / XaaS request as usual, but then we can achieve the data within the vCO workflow in to simple ways:
1. Download this vCO package, containing actions to get the parameters
2. In scriptable tasks, you can use the code I’ll exhibit below

This code is essentially the same that makes up the vCO Actions in the ASD package I linked – but i’ll break it down anyway for you lazies :)
vco asd actions

Essentially what we’re doing is just grabbing some info from the vCO server runtime, by using this code to get the ‘Requested For’ parameter


What this piece of code will return, is basically the user name for the user who the requested XaaS , Day 2 Op is for, in a user@domain format.

This can also be used in conjunction to other parts of the vCAC plugin, grabbing useful business group information like the amount of Memory or Storage that the user’s business group is currently using. Though i’d generally recommend not to rely on implementing your own policy logic, and try to enforce business group policies through the IaaS engine when you can.

Again to break everything completely down, i’ll list the options of scriptable code writing in order to retrieve these details:


Also, you can notice that these variables automatically appear at vCO’s execution tokens. Taking a close look at the ‘variables section’ we can see them:
vco asd vars

So, start XaaS-ing and build awesome services and day 2 operations, extending your Private cloud with automated!
More blogposts are coming up on cool use cases where I used this XaaS capability. Any comments you have – Below!

Harvey Specter
Posted at 5:29 pm July 22, 2014
Paul Poppleton

Thanks so much for this information. VERY helpful! I believe System.getContext().getParameter(“__asd_requestedBy”) is what I had been trying to figure out for such a long time. Hopefully this will work in an action for the default value of field. I want to feed this into an action that will lookup the users email address and set a default field value (which they can override if desired).

    Harvey Specter
    Posted at 8:20 pm July 22, 2014

    Hmmm, sounds like an interesting use case! let me know if it worked for ya :)

Harvey Specter
Posted at 4:56 pm June 2, 2015
mike hutt

I have a slightly different issue. What I want to do is set the __asd_requestedFor value from a field on my ASD form. The reason for this is that we wish to use the Requested For property to determine the approver. (in fact we want the requestedFor user to be the approver) so rather than a getParameter I need a putParameter. Any Ideas?

    Harvey Specter
    Posted at 10:08 am July 31, 2015

    These cannot be modified by vRO at runtime, so I don’t think you’ll be able to do this unfortunately.

Leave a Reply