When creating a workflow, we start with deciding what steps we are trying to perform, and then we create the lists of tasks required to be run to complete all of these steps. This full list of tasks will determine the information necessary for completing these steps, and then we must decide how much of this information we will require the end-user to enter.
To understand why we may want to limit the options available to someone running a workflow, we should consider how workflows may be used operationally within a customer organization. By hardcoding certain values for tasks, we can specify which environments a workflow can be run against or enforce that specific values or device selections are used to meet deployment standards.
Based upon the Organization where a workflow is placed, we can also restrict who can run a workflow and which devices it may be run against, as their access is determined by the org and resource group to which their account has been granted privileges. To clarify, an Intersight Org is a logical entity that supports multi-tenancy within an account through a grouping of resources.
Simple User Input
At the basic level, workflow user input includes the detail of task-level inputs which were laid out in the "Breakdown of ICO Tasks" section. Most of this is around being able to allow a user to provide input as a string and being able to evaluate those with RegEx, enter an integer and be able to ensure it is between a specific minimum & maximum range, choose from a preset list of Enum options, or use an object selector to choose a device of a specific type that exists within Intersight.
Advanced User Input
Beyond those simple input options, there is another set of functionalities that can take those simple inputs and drive a dynamic workflow experience for the user.
One of the most powerful functions that fall into advanced user input is the ability to define parameter sets or progressive disclosure rules. These rules will control the workflow inputs that are available or displayed, based on values of earlier workflow selections. To gain a better understanding of how to use these, here are some examples:
Parameter Set rule
A parameter set will explicitly control which input fields are displayed by an earlier workflow selection.
As an example, let us assume that we give the user an option to provision a volume for a single host versus hostgroup.
Based on their selection, we will ask the user to input a size in GiB for a boot volume (single host volume), or to input a size in TiB for a datastore volume (hostgroup volume).
(NOTE: Enum is essentially a specific preset value, or Enum list is a specific list of preset values).
Enum—Type is Enum and Enum list is 'Host Volume' and 'HostGroup Volume'.
BootVolumeSize—Type is String.
DatastoreVolumeSize—Type is String.
HostGroupName—Type is String.
We would then create two parameter set rules from the workflow input:
Rule 1 ("NoHostGroupOptions"): During the workflow, if the Enum value is 'Host Volume', then only the 'BootVolumeSize' field is available to choose the size in GiB for a boot volume (single host volume).
Rule 2 ("ShowHostGroupOptions"): During the workflow, if the Enum value is 'Hostgroup Volume', then only the 'DatastoreVolumeSize' field is available to choose the size in GiB for a datastore volume (hostgroup volume), along with the 'HostGroupName' field to input the name of the hostgroup where the volume will be connected.
Within the code for the Intersight API request, we can see how this would look to give an example of how these inputs are available or hidden from the user:
"InputParameterSet": [
{
"Condition": "eq",
"ControlParameter": "Enum",
"EnableParameters": [
"BootVolumeSize"
],
"Name": "NoHostGroupOptions",
"ObjectType": "workflow.ParameterSet",
"Value": "Host Volume"
},
{
"Condition": "eq",
"ControlParameter": "Enum",
"EnableParameters": [
" DatastoreVolumeSize",
" HostGroupName"
],
"Name": "ShowHostGroupOptions",
"ObjectType": "workflow.ParameterSet",
"Value": "Hostgroup Volume"
},
]The data types which can be used for Parameter Set rules are Boolean, Enum, String, Object Selector, MoReference, and Target.
Progressive Disclosure rule
A progressive disclosure rule will instead filter the data available in an input field based upon an earlier selection within a workflow. The initial input field will have the most options available, but later input fields will have limited options based on the initial input.
For example, let us assume that a user is creating a new storage host to be added to a host group.
We start with a Parameter Set rule named "ShowHostGroup" which will display a "Host Group" option to the user, if the Storage Array they choose within the workflow matches a type of "storage.PureArray".
However, we then have a Progressive Disclosure rule that will filter the list of Host Groups that the user can pick. We do this via these mappings, to be explained after the list:
Input Field Attribute: Ancestors.Moid
Operator: 'Equal to'
Source Input Field: StorageDevice
Source Input Field Attribute: Moid
For a more easily understandable explanation, let us walk through that mapping. We start with the Source Input Field being an object datatype of 'StorageDevice', which means a specific storage array object that is claimed in Intersight and is chosen from a list by the user.
Before our next step of looking for identifiers and comparing them, we want to understand the meaning of a "Moid," which is the Managed object identifier (Moid); this is essentially a GUID/globally unique identifier for the device that was assigned when it was claimed into Intersight. Now that we understand the "Moid" concept, we can explain how our progressive disclosure rules use this information for comparison.
Our rule will filter the selection list of host groups to only display those where the "Ancestors.Moid", which is the managed object ID of their parent (being the storage array) matches the "Moid" of the specific storage array, which was chosen by the user earlier in the workflow execution.
This is how the user is then shown only the hostgroups that exist on a specific storage array, rather than all host groups from every Pure array known by Intersight.
Within the code for the Intersight API request, we can see how this would look to give an example of how these inputs are available or hidden from the user:
"InputParameterSet": [
{
"Condition": "eq",
"ControlParameter": "StorageDevice.ObjectType",
"EnableParameters": [
"HostGroupName"
],
"Name": "ShowHostGroup",
"ObjectType": "workflow.ParameterSet",
"Value": "storage.PureArray"
}
],
"UiInputFilters": [
{
"Filters": [
"Ancestors.Moid eq '${StorageDevice.Moid}'"
],
"Name": "HostGroupName",
"ObjectType": "workflow.UiInputFilter",
"UserHelpMessage": "Select 'Storage Device' before selecting 'Host Group'"
}
]