Accepted Solutions
stevedrummond hi Steve, I've installed the sample code you put together, perhaps I didn't explain myself properly in the first place, but what I need to do is have an action that is used in a vro workflow presentation layer, that detects the business group that has been selected in vRA when requesting a catalog item:
Then builds a list of all managed machines within that business group, this will then be returned by the action as a string array for selection by the user in a drop down list, it should have all the managed machines that they can see within the infrastructure/managed machines page.
A search may be useful to help filter the drop-down. We may have a requirement to list just the machines owned by the logged-in user too, but that may be a different action used on a different blueprint.
Thanks,
Tim.
cloudyred thanks for the code snippet, just for test purposes, I created an action based upon your code as below:
var output = [];
try
{
var systemContext = System.getContext();
var userId = systemContext.getParameter("__requestedForUserId");
var businessGroupId = System.getContext().getParameter("__asd_subtenantRef")
if(businessGroupId == null) {
output.push("No BG");
}
else
{
output.push(businessGroupId);
}
if(userId == null)
{
output.push("No User Id");
}
else
{
output.push(userId);
}
}
catch (e)
{
output.push(e)
}
return output;
Created a workflow with a single string input, presentation calls the action.
Run the "Create a service blueprint" workflow to create the xaas blueprint in vRA.
When the action is called from vRA, I get the following:
So looks like the business group/user id can't be found in the system context?
(This is v7.6)
Yes, sorry, that is IAAS BP only. I hadn't read the thread properly.
var myContext = System.getContext();
var parameterNames = myContext.parameterNames();
var paramterValues = parameterNames.map(myContext.getParameter);
System.log(parameterNames.join(" , "));
return parameterNames.concat(paramterValues);
This is something that didn't work in vRA 7.3 (no subtenantId at least) but appeared since 7.5 so I made the assumption that was what you were looking for.
Steve is right saying that this action doesn't return any data for getContext() when called in vRO presentation layer or if used directly in a field in an XAAS form using external values.
Note that there is data for getContext() within the XAAS workflow like in a scriptable task.
__asd_catalogRequestId , __asd_subtenantRef , __asd_requestedBy , __asd_requestedFor , __asd_tenantRef , 90997ab8-66e1-43f5-afbc-29bd45a823d5 , 89787228-11a9-4f50-8368-3f1de9f08795 , ehc_sysadmin@domain.local , ehc_sysadmin@domain.local , tenant_1
I didn't import Steve's code example (which is probably why I went off topic sorry) but it sounds to exactly meet your criteria.
The major difference between your initial attempt and Steve's suggestion seem to be.
Steves approach is:
Rather than having the workflow presentation handle the filtering etc and passing info back and forth between vRA and vRO, use an action to pull back a list of accessible vm names (based on the BG / User )
Finally, bind the vmname selected to the input of your workflow and look up the vm by name possibly inside the wf.
Your initial query was:
"have an action that is used in a vro workflow presentation layer, that detects the business group that has been selected in vRA when requesting a catalog item"
=>As we have mentioned this isn't possible for an action called directly via XAAS or in the presentation.
=>You could simply add an input to your vRO workflow called businessGroup (no parameters specified in vRO presentation) and do the binding steve suggested in the XAAS form.
=>Your existing get vms action in the presentation layer could then use the businessGroup as input.
Steves approach is probably the best practice, just different to what you were expecting.
Personally I would extend this and create a vRO workflow that takes a single vc:vm and does something to it (you already have this). That would be in a folder / package that runs tasks against vcenter vms. Create another workflow with a similar name with XaaS appended but in a folder under vra/xaas. Simply add the child workflow as an element to the xaas wrapper.
--company/
--vcenter/
--vm/
--> wf "vcenter vm do task x"
--vra/
--xaas blueprints/
--> wf "vm do task x xaas wrapper"
--iaas/
--vm/
--> wf "iaas vm do task"
In this way the dev that writes the code against vcenter doesn't have to worry about vRA. Equally the team that publishes items to vRA doesn't have to worry about changes affecting the child workflow. Even if you are responsible for both, it is nice segregation. And you might say want to add a custom property to the vm in vRA while at the same time adding a vSphere tag all in the one xaas wf. Just create some actions to find iaas vm / vc vm based on name / uuid etc so it is all nice and reusable.