So you probably know that when you request a catalog item in vCAC that is based on an ASD blueprint, some global parameters about the requestor will be provided to the workflow at execution time. This is great, but in many cases one would like to create such a workflow presentation that would allow adding constraints or filtering predefined values based on the requester, before the actual request is made (before the workflow starts the execution). Well, guess what, you can do that now with the new release of vCAC 6.1 .

How would you be able to do that? The good thing is that it is re-using well known methods in both vCO and ASD, so there’s nothing new to learn, and no hidden parameters.

Let’s say that we need to create a vCO workflow, call it “Fancy Workflow”, with a presentation that will give the user the option to choose form a list of values, based on a given condition, and the condition is checking for a username or a business group. Let’s say that we are creating this presentation without even considering that it will be exposed as an ASD blueprint or resource action, we would add 2 input parameters: username (of type String) and business group (again of type String) and we would bind the 3rd parameter, that will list some values, to a vCO scripting action that based on the other 2 parameters will calculate and return some values.

The action would look like this:

and the actual binding like:

Now this is basic vCO workflow development. When you request the workflow you can specify username and/or business group and you will see the list re-calculated.

Let’s say that we now want to expose this workflow as an ASD blueprint, we name it “Fancy Blueprint”. This, again, is straightforward. However now, because we will be exposing this to end users, we don’t want them to specify usernames or business groups, both for simplification and restriction, we want this info to be populated. Now this is where the new goodies come in place.

If you open the field’s constraints editor and select Value > Field you will see that now among the fields in the form, there is one field representing complex object of user request information.

If we dig down the “Request Info” field, we will see 3 sub properties Business Group, Requested By and Requested for, all of them having other sub properties that you can drill down.

And we will bind our input fields username to the requester principal ID and the “bg” field to the Business group name of the catalog item request

The resulting form in ASD:

 

When We publish the blueprint and request the catalog item, we will see that those inputs were pre-populated by ASD, and because we use Value binding they are read-only.

When we open the drop down we will see that exactly the items that we expected for this user and this user group are appearing, and of course if we submit the request and look in the workflow execution we will see that those parameters are passed correctly, so we can even use them inside the workflow.

Note: You can use those request details in other field constraints as well e.g. Mandatory conditional constraint.