Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Initiator Conditions and Iteration

Table of Contents

Initiator Conditions

The 6connect ACP system uses “initiator conditions” as a pre-routing system to determine, based on user-given data, which step is executed first.  This is particularly useful for data unification processes. For example, a Workflow can be configured to accept both a Customer Name or a Customer Id, but if a Customer Name is provided to start at a step which first looks up the Customer Id before proceeding to the main work.  

The Initiator Editor can be accessed by scrolling to the top of a workflow and clicking ‘More options’, followed by ‘initiator conditions.’  

Image Added

The Initiator Editor consists of a series of conditions blocks identical to those found in the Conditions and Routing sections on each individual step.  The “add condition” button can be used to include an arbitrary number of initiator conditions.

Image Added

Each individual condition can describe the relation between any number of variables using the same tools available in the routing section of individual steps.

Image Added

When the workflow is executed each condition is evaluated against the user-given data, from top to bottom, in order.  One Once a matching condition is found the Workflow immediately proceeds to the indicated step.


Iteration Options

Each Step has an “Iteration Options” section which can be used to execute a single step multiple times.

Image Added

Each iteration cycle will execute the step with identical inputs, with the exception of any variables defined with the ‘iteration’ type.  These variables will be supplied with data derived from the specific iteration cycle.

...

Once a Step’s Iteration Variable is changed from “omitted,” each Input across all sections gains access to the “iteration” data type.  If selected, this input will be supplied with data from the iteration cycle.  

...

In the case of a more complicated JSON structure (ex: [ { id: 123}, {id : 321 } ] ), the entire object will be provided to the variable.  If only part of the structure is required, it can be accessed using the same semantics used to navigate JSON trees elsewhere. In the above example “{id: 123}” will be passed to the input by default, but if the input is configured with “id”, then only the value “123” will be passed inselected.  Likewise, if the object contained an array, then “2.id” will select the third item’s “id” parameter.

Sub-Steps

Each Workflow Step has an optional Sub-steps section.  This area is initially empty, but can be populated with sub-steps to create a Workflow within a Workflow.  This Inner Workflow will be executed once for each item produced by the parent Step. For example, if the parent Step produces an array of five objects, then the Inner Workflow in the Sub-steps section will be executed five times, once for each object.

The Sub-steps section is executed after the parent call, but before the data is passed to the Conditions & Routes section.

The Sub-steps section is initially empty.  The “add substep” button enables this area and navigates to a new screen which focuses exclusively on this inner Workflow.  The “back to parent” button returns to the parent Step.

The Sub-step edit screen is very similar to the normal Workflow Step editing area.  You can add individual Sub-steps, each invoking an endpoint of configured API service, connected by Conditions & Routes sections and utilizing data provided by previous Steps from both inside and outside the Sub-step area.  It works exactly like a complete Workflow, only self-contained and dedicated to manipulating the data result of a parent Step.

In general, all the rules which apply to the normal Steps of a Workflow apply to Sub-steps.

One major difference is that a series of Sub-steps does not have an “Output,” but instead has a new field in its General Options field titled “Write output in parent scope.”  This field substitutes for an Output area and allows the user to specify where to put the output of this call.  NEED EXAMPLES FROM TONY

...


Workflows

...

Executing Workflows

ACP ships with a self-referential “acp” connector type which is designed to include API calls generated by the ACP system itself.  This connector type can be found from the general list of connector types on the Connectors modal.

...

On its own, this doesn’t seem to do much, but this Workflow can be used as the first step of all subsequent Workflows, drastically cutting down on the clutter and overhead as well as allowing for easy single-point for maintenance in case of shifts in the underlying technologies.  

By creating simple workflows for very focused tasks one can build up a library of increasingly more complex combinations, allowing for very powerful results to be achieved in a compact space.


Additional Information

Continue on to additional User Guide pages for detailed information on working in ACP:

ACP User Guide

Children Display
depth1
pageACP User Guide