Can Input parameters be defined dynamically?

[PrabhuDhanaraj]

Is there a way to populate the input UI in a dynamic way? Suppose we have a list of fields for which we need to get input parameters and this list is output of a REST command in xml format, can we build a UI based on this? 

(Alternatively, can we have input parameters which are hidden by default but are made visible based on fields in the xml file)

Example: In the xml output below, the input field should take a number with the description for input being "Number of volumes"

<field>

<label>Number Of Volumes</label>

<name>numberOfVolumes</name>

<type>number</type>

<initial_value>1</initial_value>

<lockable>false</lockable>

<min>1</min>

<omitNone>false</omitNone>

<required>true</required>

<select>one</select>

</field>

[iiliev]

You cannot create UI fields dynamically. But it is possible to have fields that are hidden by default and that can made visible based on some condition/OGNL expression. Take a look at presentation of the workflow 'Invoke a REST operation with dynamic params' (part of HTTP-REST plug-in samples).

[PrabhuDhanaraj]

Actually trying to understand the "Invoke a REST operation with dynamic params" now. 

So the fields will be static i.e. the input type can be string/text but cannot dynamically change to a predefined list of elements etc? 

[iiliev]

Right.

Sorry, workflow presentation is not so dynamic.

[PrabhuDhanaraj]

Many thanks illian.

I tried the "Invoke a REST operation with dynamic params" and was able to sucessfully run it. However, to take the input, instead of un-hiding the input parameter, the content was the only text box which it presented. So I had to enter the multiple parameters there in xml format (The below URL has an example). 

The REST command I'm trying to run is detailed here -  http://www.emc.com/techpubs/api/vipr/v2-4-0-0/BlockService_createVolume_9e32046991b0878fd3253aa89eaa...

Essentially the content had to be in the below format

<volume_create>
     <name>volume1234</name>
     <size>1GB</size>
     <count>1</count>
     <project>urn:storageos:Project:7a6b150e-d224-492a-939b-57ca4d91d15a:</project>
     <varray>urn:storageos:VirtualArray:ae316135-5742-4f40-b4b0-8d38d9604917:</varray>
     <vpool>urn:storageos:VirtualPool:9cdc6936-4636-4909-a85f-3fd4c2e87e41:</vpool>
</volume_create>

So how does the UI decide that "content" was appropriate in this case? Why not individual params for name, size, count etc? Is there a way to enforce input collection in that manner?

I have added some snapshots of the above. 

Also what does the workflow "Generate new workflow from REST operation" do? In what circumstances is this to be used? 

[iiliev · Accepted solution]

The "content" is considered appropriate in this case as this is a POST operation (POST/PUT usually has a request body). Check the value of property 'Show parameter input' of 'Input content' display group in the presentation tab.

Individual parameters (name, size, count, etc.) are not shown in the UI because in your case they are part of the request body and the presentation logic in 'Invoke a REST operation with dynamic params' workflow parses only the URL parameters, not the URL body. In your case, if your REST API was POST /block/volumes/{name}/{size} the current logic would find name and size parameters in the URL. Check the values of 'Show parameter input' and 'Data binding' properties of workflow parameters in 'Input parameters' display group in presentation tab.

So you can extend this workflow, or implement your own version of the workflow, that can extract parameter information not only from URL parameters but also from the request body by parsing the request body as XML/JSON document and extracting the names of the tags.

As for what "Generate new workflow from REST operation" do - it generates a workflow that wraps the invocation of a given REST operation. In some cases, this is convenient; eg. you won't need to select REST operation to invoke every time. Also you can tweak the specific workflow (eg. add more logging, add additional processing, etc.).

[PrabhuDhanaraj]

Appreciate the detailed reply.

Even if we succeed in extracting the parameters, unless we can render it in a dynamic manner on the UI, it will not be a solution we are looking for. Given the fact the vRO UI is not dynamic just wanted to check if there is any plan to support this in future? Or alternatively can we achieve this through vRA bypassing vRO? Any suggestions?