Differences between VMware Aria Automation Orchestrator Forms and VMware Aria Automation Service Broker Forms

Starting with vRealize Automation 8.2, Service Broker is capable of displaying input forms designed in vRealize Orchestrator with the custom forms display engine. However, there are some differences in the forms display engines.

Amongst the differences, the following features supported in vRealize Orchestrator are not yet supported in Service Broker:

• The inputs presentations developed with the vRealize Orchestrator Legacy Client used in vRealize Orchestrator 7.6 and earlier, are not compatible. vRealize Orchestrator uses a built-in legacy input presentation conversion that is not available from Service Broker yet.
• The inputs presentation in vRealize Orchestrator has access to all the workflow elements in the workflow. The custom forms have access to the elements exposed to vRealize Automation Service Broker through the VRO-Gateway service, which is a subset of what is available on vRealize Orchestrator.
  • Custom forms can bind workflow inputs to action parameters used to set values in other inputs.
  • Custom forms cannot bind workflows variables to action parameters used to set values in other inputs.

---

Note You might have noticed VRO-Gateway service when you use WFs as a WBX (Workflow Based Extensibility) in Event Subscriptions where these WFs get triggered by this service.

Basically, It provides a gateway to VMware Realize Orchestrator (vRO) for services running on vRealize Automation. By using the gateway, consumers of the API can access a vRO instance, and initiate workflows or script actions without having to deal directly with the vRO APIs.

---

It is possible to work around vRealize Automation not having access to workflow variables by one of the following options :

• Using a custom action returning the variable content.
• Binding to an input parameter set to not visible instead of a variable.
• Enabling custom forms and using constants.

The widgets available in vRealize Orchestrator and in vRealize Automation vary for certain types. The following table describes what is supported.

	vRA			vRO
Input Data Type	Possible Form Display Types	Action return type for Default Value	Action return type for Value Options	Possible Form Display Types	Action return type for Default Value	Action return type for Value Options
String	Text, TextField, Text AreaDropdown, Radio Group	String	Array of StringPropertiesArray of Properties (value, label)	Text, TextFIeld, Text AreaDropdown, Radio Group	String	Array of String
Array of String	Array Input (vRA 8.2), Dual List, Multi Select	Array of StringPropertiesArray of Properties	Array of String	Datagrid, Multi Value Picker	Array of StringPropertiesArray of Properties	Array of String
Integer	Integer	Number	Array of Number	Not supported	Not supported	Not supported
Array of Integer	Array Input (vRA 8.2), Datagrid (vRA 8.1)	Array of Number	Array of Number	Not supported	Not supported	Not supported
Number	Decimal	Number	Array of Number	Decimal	Number	Array of Number
Array/Number	Array Input (vRA 8.2), Datagrid (vRA 8.1)	Array of Number	Array of Number	Datagrid	Array of Number	Array of Number
Boolean	Checkbox	Boolean	Not supported	Checkbox	Boolean	–
Date	Date Time	Date	Array of Date	Date Time	Date	Array of Date
Array of Date	Array Input (vRA 8.2), Datagrid (vRA 8.1)	Array of Date	Array of Date	Datagrid	Array of Date	Array of Date
Composite/Complex	Datagrid, Object Field (vRA 8.3)	Composite, Properties, Array/Composite, Array/Properties	Array of Composite	Datagrid	Composite(columns…)Array/Properties	Array of Composite
Array of Composite	Datagrid, Multi Value Picker	Composite, Properties, Array/Composite, Array/Properties	Array of Composite	Datagrid, Multi Value Picker	Array/Composite(columns…)Array/Properties	Array of Composite
Reference / vRO SDK Object type	Value Picker	SDK Object	Array of SDK Object (vRA 8.2)	Value Picker	SDK Object	Array of SDK Object
Array of Reference	Multi Value Picker (vRA 8.3)	Array of SDK Object	Array of SDK Object (vRA 8.3)	Datagrid	Array of SDK Object	Array of SDK Object
Secure String	Password	String	Not supported	Password	String	Not supported
File	Not supported	Not supported	Not supported	File Upload	Not supported	Not supported

For use cases where the widget specified in vRealize Orchestrator is not available from Service Broker, a compatible widget is used.

Because the data being passed to and from the widget might expect different types, formats, and values in the case they are unset, the best practice to develop workflows targeting Service Broker is to:

1. Develop the vRealize Orchestrator workflow. This can include both the initial development of the workflow or changes of inputs.
2. Version the workflow manually.
3. In Cloud Assembly, navigate to Infrastructure > Connections > Integrations and select your vRealize Orchestrator integration.
4. Start the data collection for the vRealize Orchestrator integration. This step, along with versioning up your workflow, ensure that the VRO-Gateway service used by vRealize Automation has the latest version of the workflow.
5. Import content into Service Broker. This step generates a new default custom form.
6. In addition to the input forms designed in vRealize Orchestrator, you can, if needed, develop workflow input forms with the custom forms editor.
7. If these forms call actions, develop or run these from the vRealize Orchestrator workflow editor.
8. Test the inputs presentation in Service Broker.
9. Repeat from step 5 as many times as needed.
10. Repeat from step 1, in case workflows inputs or forms need to be changed.

Either distribute and maintain the custom forms or alternatively, design vRealize Orchestrator inputs by using the same options or actions as in the custom forms (the above step 1), and then repeat the steps 2 to 8 to validate that the process works.

Using this last option means that:

• Running the workflow from vRealize Orchestrator can lead to the input presentation not working as expected when started in vRealize Orchestrator.
• For some cases, you must modify the return type of the actions used for default value or value options so these values can be set from the vRealize Orchestrator workflow editor and, when the workflow is saved, revert the action return types.

Designing the form in the workflow has the following advantages:

• Form is packaged and delivered as part of the workflow included in a package.
• Form can be tested in vRealize Orchestrator as long as the compatible widgets are applied.
• The form can optionally be versioned and synchronized to a Git repository with the workflow.

Designing the custom forms separately has the following advantages:

• Being able to customize the form without changing the workflow.
• Being able to import and export the form as a file and reusing it for different workflows.

For example, a common use case is to have a string based drop-down menu.

Returning a Properties type can be used in both the vRealize Orchestrator input form presentation and vRealize Automation custom forms presentation. With the Property type you can display a list of values in the drop-down menu. After being select by the user, these values pass an ID to the parameter (to the workflow and the other input fields that would bind to this parameter). This is very practical to list objects when there is no dedicated plug-in for them as this avoids you having to select object names and having to find object IDs by name.

Returning an array of Properties types has the same goal as returning Properties but does give control on the ordering of the element. It is done by setting for each property in the array the label and value keys. For example, it is possible to sort ascending or descending properties by label or by keys within the action.

All the workflows included in the “drop down” folder of the sample package include drop down menus created with actions that have array of Properties set as the return type.