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.

Orchestrator and Service Broker forms

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.

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.

vRAvRO
Input Data TypePossible Form Display TypesAction return type for Default ValueAction return type for Value OptionsPossible Form Display TypesAction return type for Default ValueAction return type for Value Options
StringText, TextField, Text AreaDropdown, Radio GroupStringArray of StringPropertiesArray of Properties (value, label)Text, TextFIeld, Text AreaDropdown, Radio GroupStringArray of String
Array of StringArray Input (vRA 8.2), Dual List, Multi SelectArray of StringPropertiesArray of PropertiesArray of StringDatagrid, Multi Value PickerArray of StringPropertiesArray of PropertiesArray of String
IntegerIntegerNumberArray of NumberNot supportedNot supportedNot supported
Array of IntegerArray Input (vRA 8.2), Datagrid (vRA 8.1)Array of NumberArray of NumberNot supportedNot supportedNot supported
NumberDecimalNumberArray of NumberDecimalNumberArray of Number
Array/NumberArray Input (vRA 8.2), Datagrid (vRA 8.1)Array of NumberArray of NumberDatagridArray of NumberArray of Number
BooleanCheckboxBooleanNot supportedCheckboxBoolean
DateDate TimeDateArray of DateDate TimeDateArray of Date
Array of DateArray Input (vRA 8.2), Datagrid (vRA 8.1)Array of DateArray of DateDatagridArray of DateArray of Date
Composite/ComplexDatagrid, Object Field (vRA 8.3)Composite, Properties, Array/Composite, Array/PropertiesArray of CompositeDatagridComposite(columns…)Array/PropertiesArray of Composite
Array of CompositeDatagrid, Multi Value PickerComposite, Properties, Array/Composite, Array/PropertiesArray of CompositeDatagrid, Multi Value PickerArray/Composite(columns…)Array/PropertiesArray of Composite
Reference / vRO SDK Object typeValue PickerSDK ObjectArray of SDK Object (vRA 8.2)Value PickerSDK ObjectArray of SDK Object
Array of ReferenceMulti Value Picker (vRA 8.3)Array of SDK ObjectArray of SDK Object (vRA 8.3)DatagridArray of SDK ObjectArray of SDK Object
Secure StringPasswordStringNot supportedPasswordStringNot supported
FileNot supportedNot supportedNot supportedFile UploadNot supportedNot 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s