Steps

Recipe steps can be actions or control flow statements that help you describe business logic.

Action step

Actions carry out an operation in your target app, typically a create, update, or search operation. Each action requires a set of input fields and typically returns data i.e. output data tree.

Example: Action step

The following step carries out a Search organizations action in a Zendesk integration. The input fields on the left shows the available fields to search for a Zendesk organization by:

• Name

• Tags

• Notes

• Details

In the following case, the Search organization action is carried out by name.

When the Search organizations action has been carried out, Zendesk returns data about the organizations found, if any. The output datatree displays available fields for mapping in subsequent steps.

In the following case, the Update organization action uses the ID field from the Search organizations action to identify which Zendesk organization to update (ID field as highlighted).

Conditional action step

Conditional actions will only be carried out if the specified condition is true. All actions indented within a conditional action block will be carried out only if that condition is true.

Example: Conditional action step

The following Recipe has two conditional steps:

• If Zendesk organization was found, update Zendesk organization

• If Zendesk organization was not found, create new Zendesk organization

In this example, any job can only proceed through either one of the conditional steps, as the Zendesk organization must have either been found or not.

Repeat step

When working with a list of items (e.g. a list of invoice line items), you may need to carry out a set of actions for every item in the list. The repeat step helps you do that.

Actions indented within a repeat block will be carried out for all items in the list.

The input to the repeat step is a list. Actions within a repeat block should use data output from the Repeat step's datatree. This ensures that every item in the list is processed.

Example: Repeat step

Refer to the example scenario of syncing new lines in a CSV file in Dropbox (using the batch trigger) to organizations in Zendesk.

In this example, the trigger returns a list of new lines in a CSV file in Dropbox. Since Zendesk does not support batch actions, each line must be added one at a time from Dropbox to Zendesk.

The list datapill has to be passed into the repeat step. When the input list field is selected, only list type datapills are usable in the datatree, as shown below. List type pills can be identified via their stack icon.

Datapills from the Foreach output datatree should be mapped to ensure that values from each list item are used when the action is repeated.

For example, if two organizations are fetched by the trigger, using pills from the Foreach datatree ensures that the Create organization action creates a Zendesk organization with the data from the first CSV line account on its first iteration, then with the data from the second CSV line on its second iteration.

Repeat in Batches

Occasionally, the rate at which an upstream app or system transmits the data is faster than the rate at which a downstream app or system can receive it.

You can use the Repeat in Batches feature to process such a data movement by configuring the batch size. Large data sets are automatically parsed into smaller batches for transfer.​

How to use

Follow these steps to use the Repeat in Batch feature:

1. Select the Repeat Action step from our “What happens next” container in the Recipe Editor.

2. Enter the Input List data pill in the Repeat Action step.

3. Invoke the Repeat in Batches feature by setting Repeat Mode to “Batch of items”. (The two options available are “One item at a time” and “Batch of items”.) Refer to figure below for more details.

4. Set the Batch size field. This defaults to 100 when the batch size is not specified or if the number specified is less than 1. Please note that a data pill can also be input here as a batch size.

5. You will see this reflected in the For each statement with the batch event tag.

Call Recipe step

Call Recipe will run another Recipe (named a callable Recipe). Callable Recipes are like functional calls in programming languages. They offer an easy way to reuse Recipe logic.

You should note that callable Recipes are executed synchronously. i.e. the calling Recipe will be blocked waiting for the called Recipe to finish processing.

Stop step

The stop step ends a single job from being processed any further. It is usually used in cases when there is an error in the business logic and further processing of the job is not required.

The stop step can be configured to mark the job as a failed or a successful, depending on business logic.

Example: Stop step

The following Recipe expects all Insightly organizations to be present in Zendesk as organizations. In cases where no corresponding Zendesk organization is found, the recipe will stop processing further actions.

Any job ran by this Recipe can proceed through either one of the conditional step, as the Zendesk organization must have either been found or not.

If not found, the job will stop at Step 4. If found, the job will not carry out actions within the conditional step (Steps 3 and 4), instead only updating the matching Zendesk organization.

This Recipe marks the job as an error, so that the recipe owner will take notice of this job and attempt to rerun it.

Action with error handler step

This step allows you to monitor for errors in actions, similar to the try/catch concept in programming languages. When an error occurs, you have the chance to:

1. Retry the sequence of actions again, in case it was a temporary error such as network issues, or

2. Take remedial actions, such as notifying users of the error via email or error messages in the app, or to carry out a rollback (i.e. reversing the job by deleting any created or half-created records).

This step consists of 2 blocks: the Monitor block and the Error block. Actions to be monitored for errors should be within the Monitor block. If all actions are successful, the Error block will be ignored. However, if any action in the Monitor block results in an error, the actions within the Error block will be executed.

Auto-retry

When using the error monitor step, you can setup the actions within the Monitor block to be auto-retried by AppConnect in cases of action failures. By default, the Monitor block actions will not be reran.

You have the option of retrying up to 3 times, and of selecting the time interval to wait between each retry.

You can also define a condition that has to be met before the Monitor block can be auto-retried.

Configuring the retry condition field. In this example, the actions in the Monitor block will only be carried out again if the error message does not contain the 401 error code.

Example: Error monitor step

The following Recipe tries to update the Zendesk organization right after the search step, regardless of whether any Zendesk organizations were found.

In cases where no matching Zendesk organization is found, the Update organization action will fail.

As the Recipe catches failed actions within the error monitor block, failed Update organization actions will be caught, and the Recipe proceeds to carry out steps within the Error block immediately, as no auto-retry was configured.

In this case, it seems that the only reason for the update failing is because no matching Zendesk organization was found. Hence the remedial step creates a new Zendesk organization.

Example: Error monitor with retry step

If the actions in your Monitor block tends to fail for temporary reasons such as network issues or timeout issues, it would make sense to use auto-retry, such that the Recipe will attempt to execute the steps again until it succeeds, for a maximum of 3 tries.

We will reuse the same error monitor example Recipe from above, where we try to update the Zendesk organization right after the search step, regardless of whether any Zendesk organizations were found. In cases where no matching Zendesk organization is found, the Update organization action will fail.

If updating the Zendesk organization fails, the Recipe will check to see if the error message contains a 401 error code (i.e. unauthorized error).

If the error is an unauthorized error message, we know that further attempts will still fail as this means we don't have the right permissions to update the Zendesk organization, perhaps because of changed permissions.

If the error is not an unauthorized error message, we will proceed to retry the update organization action again after the specified period of time, e.g. 5 seconds, up to a maximum of 3 tries.