VMware Cloud Community
manfriday
Enthusiast
Enthusiast
Jump to solution

dynamic inputs in the web client

Hi!

I have a workflow I am working on that uses some dynamically changing inputs.

I.e..

Selecting a host from drop-down causes two other drop-down selectors to populate with information relevant to that host.

This works great in the Orchestrator workflow designer.

However, in the vSphere web-client the fields are not updated when a host is selected. They seem to just get populated with default values for the data type (StoragePod, and ResourcePool)

I know not everything that works in the workflow designer translates in the web client. Am I just running into that issue, or do you think there is a way I can work around this?

My main goal is speeding up the interface by presenting only the relevant selections to the user, without them having to dig through a slow tree-view for the item they want to select.

Thanks for any insight you can offer

Jason

Reply
0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

This scenarion should work in web client.

How do you compute the values of dependant fields? Do you use vRO scripting actions that eg. accept a host as an input and return a dynamically computed list of objects to show in the dependant field? If so, please ensure that the scripting code properly handles null input value and does not throw an exception or return null if the input is null, but instead returns an empty list [].

If the above doesn't solve the problem, could you prepare and attach a sample workflow demonstrating the problem (plus some details about your environment, like versions of vRO and web client)?

View solution in original post

Reply
0 Kudos
4 Replies
iiliev
VMware Employee
VMware Employee
Jump to solution

This scenarion should work in web client.

How do you compute the values of dependant fields? Do you use vRO scripting actions that eg. accept a host as an input and return a dynamically computed list of objects to show in the dependant field? If so, please ensure that the scripting code properly handles null input value and does not throw an exception or return null if the input is null, but instead returns an empty list [].

If the above doesn't solve the problem, could you prepare and attach a sample workflow demonstrating the problem (plus some details about your environment, like versions of vRO and web client)?

Reply
0 Kudos
manfriday
Enthusiast
Enthusiast
Jump to solution

Hi!

Thanks for your input!

I have a couple of actions that are being called when a host is selected.

One of the actions takes the host and spits out an array of ResourcePool reflecting only the Resource Pools that host has access to:

var ResourcePools = new Array();

ResourcePools = [];

var parent = host.parent;

var rp = new Array();

if(!host){

     return ResourcePools;

}

rp = parent.resourcePool.resourcePool;

for each (var i in rp) {

     ResourcePools.push(i);

}

return ResourcePools;

The other action takes a host and spits out an array of StoragePod, reflecting only the StoragePods that host has access to:

var datastores = host.datastore;

var DSCluster = new Array();

var DSNames = new Array();

DSCluster = [];

if (host = null) {

     return DSCluster;

}

for each (var ds in datastores) {

     if (ds.parent instanceof VcStoragePod){

     if(DSNames.indexOf(ds.parent.name) == -1) {

          DSNames.push(ds.parent.name);

          DSCluster.push(ds.parent);

          }

     }

}

return DSCluster;

These actions seem to work fine in the workflow designer.

In the Web Client, the fields seem to get populated with whatever default values are pulled (based on their data type), and are not modified by the actions.

I'm wondering if I need to output an array of strings rather than StoragePod and ResourcePool, and then get the correct datatype again in the actual workflow logic?

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

Hi,

Both actions contain some incorrect code/logic.

In the first action, the check whether host parameter is valid or not (line 5) is done after the parameter is been already accessed (line 3).

In the second action, the if operator is not a comparison ('==') but assignment ('='), which will nullify the host parameter value instead of comparing it to null.

manfriday
Enthusiast
Enthusiast
Jump to solution

Ahh! Yep, you were right on all counts.

I fixed my dumb logic errors, and everything worked great.

Testing for a null value and returning an empty list was the way to fix the issue.

Thanks so much!

Jason

Reply
0 Kudos