You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Initiator Conditions and Iteration

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.’  

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. Each individual condition can describe the relation between any number of variables using the same tools available in the routing section of individual steps.

When the workflow is executed each condition is evaluated against the user-given data, from top to bottom, in order.  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.

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.

The Iteration Variable field in the Iteration Options section accepts the normal set of ACP variable types.  If supplied with a simple numerical value (ex: 5), the step will iterate that number of times. If supplied with a JSON array (ex: [ { id: 123}, { id : 321 } ] ), the step will repeat once for every member of the array.

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 simple numeric iteration, the data supplied will the iteration count, starting from zero.  

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 selected.  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 a 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 deposit the results in the parent's data object.  These results will then be available to all subsequent steps as the Outer Workflow proceeds.

Each Inner Workflow can have, if needed, Sub-steps of is own, creating an Inner-Inner Workflow.  There is no limit to how many Workflows deep this can go.


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.

This functionality is extremely useful as it allows the user to extend simple workflows into more advanced ones in an intuitive fashion.

For example, imagine a situation where a Workflow integrates between some 3rd party billing software and customer information stored in 6connect ProVision.  A simple workflow might accept user credentials (user names, account numbers, etc) and then verify them with ProVision, the billing software, or both. This simple workflow would return the user object on success, but an error on failure.

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 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.

  • No labels