In this document, we will walkthrough a simple ICO workflow that has been created within the platform
To describe these in simple terms, a workflow is a sequence of tasks which are connected together to accomplish a specific operation. A simple workflow might contain one or only a few of tasks to perform relatively simple, but repetitive, IT operations.
For a walkthrough of a basic workflow, we are working with a cloned instance of a built-in/system workflow, so that we can follow along to understand how these tasks are connected to make the workflow function.
The example that we are using here is the 'New Storage Host' workflow, which will run two tasks:
- New Storage Host – This task creates a new storage host from a host name & list of IQN/WWNs to be added to it.
- Add Host to Storage Host Group – This task takes input of a host name and hostgroup name. It then adds that host name to the hostgroup. Both the host & hostgroup must already exist.
To walk through the workflow design in a manner similar to the layout of our previous documents, we will start with the General tab of the Workflow Designer.
Based on the two tasks that are built into this workflow, we have 8 inputs which are possible for this workflow, although only a few of them are required (denoted with an * after the input name).
Storage Device * - This input uses the object selector for the user to choose a storage device already climed within Intersight
Host * - This input is simply for a text string as the name of the host to be created on the array
Storage Vendor Host Identifier * - This input simply helps to connect the initiators from the user input to the correct host identifier field, based on the type of storage array chosen by the user in the 'Storage Device' selection
Storage Vendor Virtual Machine Name * - This input connects to a storage virtual machine name, if required by the storage platform; this input exists due to these tasks being a generic/vendor-agnostic construct
WWNs – This input is a list of strings for the WWNs to be configured for the host
IQNs - This input is a list of strings for the IQNs to be configured for the host
Storage Vendor Host Options * - This input simply helps to correct storage array device options, based on the type of storage array chosen by the user in the 'Storage Device' selection
Host Group - This input is simply for a text string as the name of the hostgroup the host will be added to; the hostgroup must already be created on the array
Due to the fact that this workflow is leveraging built-in system which are intended to be a generic/vendor-agnostic construct, we need some rules for input validation. Two of these rules will dynamically adjust the input options displayed to the user, based on the type of storage array they choose for the workflow, and one final rule will filter a list of options for a user.
We will begin by explaining the two input rules relevant to Pure Storage that are in this workflow:
Our first rule that is in use is a Parameter Set rule called 'ShowHostGroup'. This rule defined that the 'Host Group' input field will only be shown to the user when the StorageDevice is equal to a value of "storage.PureArray". This means that a user will only ever see the "Host Group" field if the 'Storage Device' they select is a Pure FlashArray.
Before Storage Device selection:
After Storage Device selection:
Our second rule is a Progressive Disclosure rule for the 'Host Group Name'. This is in interesting instance, as the rule itself will filter the list of host group names to match only those where the parent Moid (Managed object identifier) is equal to the Moid of the selected 'Storage Device'. This means that a user will only be able to choose a Hostgroup that already exists on the Pure FlashArray which was selected as the 'Storage Device'.
This screenshot shows the available 'Host Group' objects to choose from after we select a Pure FlashArray.
'Host Group' list displayed after Storage Device selection:
Now that we have taken a look at our inputs and input rules, let's look at the mappings that we are using in this workflow, and then explain what these mappings are doing.
In the leftmost column, we can see all of the workflow inputs that we listed in our 'Inputs' section above. Each of these workflow inputs shows a second line that identifies which data type that specific input is defined as
Between the first and second columns, we can see where each workflow input is mapped to specific inputs for the two tasks of 'New Storage Host' and 'Add Host to Storage Host Group'. From the arrows that show each mapping across these columns, we can see that only the 'Storage Device' workflow input is mapped to more than one task input.
Within the third column that lists our task outputs, we can see that the 'Storage Host' object which is output from the 'New Storage Host' task is then mapped to the 'Host Name' input for our 'Add Host to Storage Host Group' task. While this can be confusing to follow along with in a text description, the arrows of the graphical representation of this are quite easy to follow.
The final column shows that we do not have any workflow outputs.
Function & Result of the Workflow
To give a clear explanation of what is happening during the execution of this workflow (assuming no errors or failures), we will walk through the steps of each task.
For this example, we are providing the following input:
Storage Device: pure-Zw7ukLIf (chosen from object selector)
Host Group: demo-hostgroup (chosen from list of existing host groups)
WWNs: 20:00:00:25:B5:21:A1:04, 20:00:00:25:B5:21:B1:04
First, an API call is initiated from ICO to create our host with the initiators to be connected.
Command/subcommand/arguments from Pure FlashArray audit log:
purehost create basic-walkthrough --iqnlist iqn.2023-10.flashstack.lab:esxi-host:18 --wwnlist 20000025B521B104,20000025B521A104
Next, an API call is initiated from ICO to add our host to the hostgroup.
Command/subcommand/arguments from Pure FlashArray audit log:
purehgroup setattr demo-hostgroup --addhostlist basic-walkthrough
Upon completion of the workflow, we have our host with connected initiators, which has been added to our hostgroup.