The Step Listing
Workflows are represented as a series of steps (see ‘Getting Started 3. Connecting Steps’ from the examples library). Step headers in blue are initiators, and are candidates for being the first step executed when the workflow is invoked.
Step headers in green are dependent steps and may or may not be executed depending on the specific routing logic built into the workflow.
Step headers in red are steps which have produced errors when executed. These can happen for a variety of reasons, including omitted required values, data type mismatches (ie, a string instead of an integer), or a failure to find an appropriate route in from the Conditions & Routes section.
Step headers in red also display a ‘view response’ link on the right-hand side. This can be clicked to bring up a window which shows what the API service is responding with. This can be very helpful in debugging. Also, turning on Debug Mode can show the full logical pathway of the ACP Workflow.
A new step can be added by using the ‘Add New Step’ form at the top of the screen. Select the connector you want to use, then the API Endpoint Family, then the specific API Endpoint you are interested in.
Steps can be removed from a Workflow by clicking the ‘x’ button on the far right of their entry.
Steps can be re-ordered by using the arrow buttons on the left of their entry.
The output section is required cannot be removed. An ACP workflow must have at least one step in addition to the output section.
Anatomy of a Step
Clicking on any step header will expand the step to reveal the individual sections which the it uses to define its behavior. The step header also has a series of buttons on the right which allow you to move the step up in the workflow-order, move the step down in the workflow-order, execute this step in isolation (useful for debugging), and to delete this step from the workflow entirely.
The first section is ‘General Options,’ and it contains a field where you can add a description of what the step is trying to accomplish. You can also customize the name of the step. This section also provides a list of user-given inputs used in this step.
The second section is for ‘Required Inputs.’ These are the variables that must be set for the API call to proceed. This section is not always present, as not all API calls have required parameters.
The third section is for ‘Optional Inputs,’ which are those parameters that the API call might make use of which are not explicitly required. Some APIs are flexible and allow you to add additional optional parameters. To allow for this, the ‘add input’ button will allow you to define an additional optional input to complete the API call.
Both types of inputs have a small green ‘?’ next to their name which will supply help text as to what that parameter does. For more details, see the official API documentation for the API service you are using.
Both types of inputs can be customized with the following states:
- Omitted. The default state. This parameter will not be sent with the API call.
- Default value. This parameter will be set to some constant, defined here.
- User given. This parameter will be supplied by the user executing the ACP Workflow.
- Workflow link. The input for this parameter is the output of another step. This will be described in greater detail later.
- Iteration. This parameter becomes available when the Iteration Options section is configured. Inputs set to ‘iteration’ are populated with the iterated run number, starting from zero. This will be described in greater detail in its own section.
- Function. The input of this parameter will be supplied by the output of a javascript function. This will be described in greater detail later.
If there are no optional inputs for a given API call, the entire section is hidden.
The fourth section is ‘iteration options,’ which deals with how to loop over array responses. This section will be covered in more detail later.
The ‘Sub Steps’ section describes how to iterate over an array of return objects, similar to the ‘iteration options’ previously. This will be described in more detail later.
The ‘Conditions & Routes’ section describes the flow-control by which the ACP system chooses what step is next. The logic involved is complicated and receives its own section later in this document.
Lastly, the ‘Output’ section shows an example return of the API endpoint, for use in establishing Workflow Links.
Links Between Steps
Setting a Required Input or an Optional Input to be a ‘workflow link’ will indicate that this parameter is to be taken from the results of a previous step. The result can come from any previous step so long as it has run.
When the ‘workflow link’ option is selected the form expands to gather the necessary information. The middle drop-down selects what step you will be taking this information from. Once a step is selected, the rightmost ‘property’ box accepts the name of a parameter.
For example, if you are referencing a ProVision Resource GET call you can specify ‘id’ or ‘name’ here to feed in the associated value to this parameter.
If the step you are referencing returns an array of items, you can specify which item in the array you reference by way of the syntax ‘index.property’. For example, if an API call returns an array of 3 objects, and you want to reference the id of the last one, you would put ‘2.id’ in the ‘property’ field.
A simple example of using the ‘workflow link’ parameter can be found in the ACP examples library as ‘Getting Started 3. Connecting Steps.’
Another example can be found in ‘Getting Started 9. Working with Arrays.’ The Output area contains a reference to ‘2’, which indicates the entire 3rd object returned by the ProVision Get Resources query.