Execution, the Results Area, and Debugging
Workflows can be run using the blue “Execute” button in the far upper right. When a Workflow is executed, the system scans the Workflow’s structure to determine what information is required from the user as inputs and presents a modal screen requesting it. Once this data is supplied, the screen scrolls to the Results area at the very bottom of the Step List and displays the results.
The Results section is broken into three sections: Status, Stepwise Debugging, and the Raw Output. These sections can be navigated between by clicking on their names (in blue) just below the Results header. The current section is underlined.
The Status screen shows the broad results of the Workflow. If the workflow executed successfully the amount of time it consumed will be displayed in green.
If the workflow encountered an error and halted, this error will be shown in red.
The output box below the response shows the data that has been returned by the Workflow. In the case of a successful execution, this will be the data described in the Workflow’s Output section. In the case of an error it will return a JSON debugging structure which contains an error message and a summary of what calls were executed.
If Debug Mode (see the section “Rollback Mode and Debug Mode” in this documentation) is enabled then the Steps and Raw Output sections are available. These areas provide additional information on how to diagnose issues with ACP Workflows.
The Steps section shows the list of ACP Steps and lists the HTTP code returned at each step. If a step is not run, the HTTP code is listed as “HTTP N/A.” Clicking on each step displays the variable values that were used in the execution of that step, as well as the output that was returned and the next step taken by the system. This can be used to trace the flow of data throughout a workflow to determine where an issue occured.
The Raw Output section displays the raw JSON returned by the ACP system. The details of this area are beyond the scope of this document, but this data can provide additional insight into the behavior of the Workflow.
Workflow URL and External Execution
Once saved, every Workflow is assigned a distinct URL which can be used to execute it remotely by POST’ing data to it. This URL can be found by navigating to the header area of the Workflow and clicking on the ‘More options’ drop-down below the description area.
Then select the ‘Workflow Info’ option.
A modal window appears which displays the Workflow URL and the user-given variables required for the Workflow to run.
Export
Workflows can be exported in JSON format by navigating to the header area of the Workflow and clicking the ‘More options’ drop-down below the description area.
Then select the ‘Export as JSON’ option.
The Workflow JSON will be downloaded through the browser. This exported JSON can be saved as a backup, shared with coworkers, or sent to 6connect Support for assistance.
Initiator Conditions
The 6connect ACP system uses “initiator conditions” as a sort of 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 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. One 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 in the Required Inputs section and the Optional Input gains access to the “iteration” data type. If selected, this means that 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 passed in. Likewise, if the object contained an array, then “2.id” will select the third item’s “id” parameter.
Javascript Functions
While many API automation tasks can be completed by invoking endpoints in order and passing identifiers from one service to another, many tasks will require some data processing to correctly accomplish their goals. To assist in this ACP offers the ability to include user-written Javascript functions to handle these data manipulation tasks.
The Javascript Functions Management screen can be accessed from the left-hand menu by clicking on the pages icon, below User Management and above Generic Connectors.
The Javascript Functions Management screen contains a listing of all the Javascript Functions currently known by the system. When Workflows are exported, all used Javascript Functions are packaged in the Export bundle. When Workflows are imported, these packaged Functions are automatically included in the listing of Javascript Functions.
Each Javascript Function has a name, an optional category, and a description. The Management screen contains boxes to search for a given Function by name and to filter by category. Click on an existing Function name to edit the Function.
New Javascript Functions can be defined by hitting the ‘Add Function’ button at the top of the screen.
This opens up a short window where you can give a name to the new function, provide a description, assign it a category, and provide the code. All Javascript Functions take the following form:
return function() {
return "Hello World;"
}
Each Function can accept an unlimited number of arguments and produces exactly one return value. Each Function can be of unlimited length and contain whatever logic is required to accomplish the Function’s goals.
All internal Javascript functions are available, but no Javascript extensions or libraries.
Javascript Functions are used wherever a variable is required in an ACP Workflow. They can be used to transform Required or Optional Input data, or in Conditions & Routing blocks, or anywhere else a variable type box is displayed.
To use a particular Javascript Function, open the variable type drop-down and pick ‘function.’ Click the ‘select function’ box to bring up the Function Picker.
The Function Picker allows you to filter the list of known Functions by name and category. Choose a function by clicking on it from the Function Listing on the left.
Once you have selected a Function the next step is to supply it with inputs. Click the “add argument” button to add the correct number of inputs for this Function. These arguments will be passed to the Function in-order from top to bottom when the Function is executed. Each argument comes with its own variable type picker and can consist of user-given data, workflow links, or default values.
Save the configuration by clicking the ‘add’ button at the bottom of the screen.
This variable will be now be populated with the results of the function whenever this step is run.
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
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.
Generic Connectors
The Generic Connector system is designed to allow ACP to support API-providing systems which do not have a predefined built-in connector. For example, there may be a network appliance which offers an API that ACP does not natively support. In this case the user can employ a Generic Connector to manually define the API endpoints offered by this appliance and then integrate its functions with an ACP workflow as normal.
The Generic Connector section can be found by clicking on the graph icon on the left-hand navigation bar.
This brings up the main Generic Connectors List screen.
The Generic Connectors List screen. From this screen you can edit or delete existing Generic Connectors.
Clicking on ‘Add Connector’ brings up a form which allows the user to name the new connector, add a short description, and pick the authentication type and communications protocol this connector will employ.
Authentication methods currently supported are “HTTP Basic”, “vCenter”, and “None.”
The only communications protocol currently supported is “HTTP.”
Completing the form and clicking the ‘add’ button will add the Generic Connector to the connectors list.
Endpoints can be added to a Generic Connector by clicking on the ‘edit’ icon to the right of each Connector’s name. This brings up a screen which displays a form for adding new Endpoints above the list for managing existing Endpoints.
The General Options area is where the information necessary to properly execute the API action is defined. There are several fields:
Unique call name: the name for this endpoint within ACP.
Endpoint http method: the HTTP header for accessing this endpoint (GET, POST, etc).
Endpoint pathname: the path of this API action. Note: the connector configuration modal on each ACP Workflow will ask you for the location of the API service. This pathname is the path to be used *after* the location of the service is defined. For example, if an API endpoint is “https://127.0.0.1/services/action1/”, the connector location will be defined as “https://127.0.0.1/services” and the endpoint pathname will be “/action1/”.
Endpoint family name: ACP organizes API endpoints into families for easier lookups. This field allows you to define what family this endpoint falls into. Families are automatically created from the contents of this field.
Friendly endpoint name: a more user-friendly name for this endpoint.
Endpoint description: a short description of what this endpoint does.
Rollback call: the unique call name which will be invoked if this call fails and rollbacks are enabled. Optional.
Use this call to test credentials: When the user is filling out the connector’s location and authentication details in a Workflow the ‘test’ button does a quick call to a specified endpoint to verify the credentials are working. This toggle defines whether or not this endpoint is appropriate for this test.
Content-type header: The content-type header sent to the API service by the HTTP protocol.
Once a Generic Connector has been defined it can be selected from the Connectors section of any Workflow.
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 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.