iterate
This action iterates through supplied array data to forward each item to the named workflow in the named engine for processing. Each item of the array is added to the "item" workflowContext key along with the contents of the current workflowContext or the optional context (which must be a JS Object).
Note
This action might process the elements of an array out of order, but in many situations this does not matter, as in the example below.
This function is available as a feature of the Add-ons v2.3.5 download and later.
This function is available for alert and Situation workflows.
Back to Workflow Engine Functions Reference.
Arguments
Workflow Engine function iterate
takes the following arguments:
Name | Required | Type | Description |
---|---|---|---|
data | yes | string | The name of the field or workflowContext key holding the array data to process. |
engineName | yes | string | The name of the target workflow engine — case sensitive. |
workflowName | yes | string | The name of the correlated service. |
context | no | string | The optional JS Object to send - if omitted the current workflowContext will be sent. |
Example
Suppose you receive alerts that include a list of devices whose IPs are adjacent to the source of the alerts. The neighboring devices are contained in the array custom_info.eventDetails.neighbours
. We want to use the data in the alert to populate an 'ip_neighbours” topology. There are existing actions, addTopologyNode
and addTopologyLink
, that you can use to update a topology using individual neighbors taken from the alert data.
First, create an workflow called AddIpNeighbor in the Alert Inform Engine to process each individual neighbor:
This consists of a single action “Add Link” that uses the addTopologyLink
method to create a link between the source and the neighbor nodes.
Next, create the ProcessNeighbours workflow in the Alert Workflows engine to use the iterate action to extract each neighbor from the custom_info.eventDetails.neighbours
array and forward to the AddIpNeighbour workflow to add it to the topology:
With that in place, given this alert:
{ "signature": "network::availability::host1", "source_id": "192.168.1.1", "external_id": "EXTERNAL_ID", "manager": "Pinger", "source": "host1", "class": "network", "agent": "RESTLam", "agent_location": "AGENT_LOCATION", "type": "availability", "severity": "5", "description": "Ping down for host1", "custom_info": { "eventDetails": { "neighbours": [ "host2", "host3", "host4" ] } } }
The two workflows working together will create individual nodes for “host1”, “host2”, “host3” and “host4” in the “ip_neighbours” topology and the links from “host1” to each of “host2”, “host3” and “host4”.