Data adapters

Tick does not exist in a vacuum, but strives to integrate with your existing processes and software. Use adapters to pull data in to Tick, or send data elsewhere.

What you should know first

• Know how "states" work => They are used often in flows and metadata components

When is an adapter executed

• As part of a flow step

Execution diagram

flowchart TD
    start[Call external API] --> execute{Success?}
    execute ---->|No| Retry[Retry on failure? ]
    Retry[Retry after increasing timout] --> start
    execute ---->|yes| store{Store actions?}
    store --> |NO| Finish
    store --> |Yes| executeStore[Store into states]
    executeStore --> Finish

Preparation

Before the external API can be called the call must be prepared.
Tokens from the following parts of the request will be replaced with their values from the state - URL - Authentication header - Headers - Body Skipped when it is a GET method

Call external API

The External API is called and awaited for max 10 seconds. There are some possible outcomes: - Success (Http status code 200 to 299) => Continue to Store actions - Failure due to API not being reachable - Failure due to internal issues such as authorization, bad requests or server errors

On Failure

Whenever a failure is detected we will retry a few times to see if your API is callable again, when not the Adapter can Log the details See debugging

Store Actions (optional)

Yeah! Tick's API responded with "Ok" and you might just want to do something with it's response data.
You can have multiple "actions", in each action you can: - pick data from the response - transform the picked data (see transformations) - store the transformed data in a state for further usage

Debugging

Each adapter is configured to: - Always log => Handy for when configuring and debugging - Log on failure => Normally used for production - Never log => When you don't want to seen the errors from your API