Automation Iterator Anatomy

To better understand the power of automation iterators and their definition, we define and describe their anatomy.

Automation iterator are constructed with the following methods:

i: Defines the resource, action and the filter used for resource fetching. Passed object must conform to the interface:

interface {
  resourceType: string; (1)
  eventType: 'onManual' | 'onInterval' | 'onTimestamp' = 'onManual'; (2)
  action: 'update' | 'delete' | 'clone' | '' = ''; (3)
  filter: IteratorFilter; (4)
}

1	define the resource type; see [ext-resevt] for details.
2	define the event type; see [ext-resevt] for details.
3	define what action the script performs; see Iterator actions for details,
4	define the filter to use; see Filter for details. `i.at` Defines that the automation script is executed at a specific time, `i.every` Defines the interval in which the automation script is executed,

Iterator actions

update: The result of the automation script will be used to update the original resource,
delete: The result of the automation script will be used to delete the original resource,
clone: The result of the automation script will be used to create a new resource with updated values; original resource is left unchanged,

Iterator script doesn’t perform any operation on the resource except if explicitly specified by the action property.

Iterator and trigger are not compatible; you can only use one or the other within the same automation script.

Filter

Iterator filter provides ability to write query (conditions), sorting, limit and offset rules It closely resembles Corteza’s filter object and conforms to the following interface:

interface {
  query: string; (1)
  sort: string; (2)
  limit: number | string; (3)
  offset: number | string; (4)
  [_: string]: number | string; (5)
}

1	SQL like query filter to use (`WHERE <query>`).
2	SQL like sort to use (`ORDER BY <sort>`).
3	Maximum number of resource.
4	Offset from first record.
5	additional non-standard resource specific parameters.