cenithub presentations | 4- flows, connections & webhooks

CenitHubChapter 4

Flows, Connections & Webhooks

Flows

A flow defines how data is processed by the execution of one or more actions.

Data processing involve:

₋ An execution trigger to start the data processing.₋ Data types.₋ Translators.₋ Connections & Webhooks, if the data is coming in to Cenit or going out of Cenit.

Flow: execution triggers

Flows processing can be manually invoked or through the occurrence of events.

Events are of two types:

- Observers: listen for properties changes on records.

- Schedulers: they occurs periodically.

Flow: translator

Every flow have a translator that performs the main data processing.

Depending on the translator type a flow can:

- Pull (import) data into Cenit- Export data outside Cenit- Update/Convert data inside Cenit

A flow must define a data type unless its translator defines one.

Flow: scope

If a flow is not of type import then it must define a scope for data processing.

The scope can be defined depending on the flow event, translator data type or the flow custom data type:

- Event source process only the record who fire the event

- All records scope process all the records

- Filter scope process the records following some criteria.

Flow: update/convert

When the flow translator is of type update/convert no further configuration is needed beyond the scope.

The active option prevent the flow processing even if its event is fired when it is not checked.

Flow: import/export

When the flow translator is of type:- Import, then the data will be pulled

into Cenit- Export, then the data will be send

outside Cenit

In any case an end-point is needed to pull or send the data.

An end-point is determined by a connection and a webhook

Connections

A connection consist in an URL and a set of parameters, headers and template parameters.

The connection URL, parameters and headers can be described by using Liquid Templates.

The template parameters and its values are available in the Liquid Templates as local variables so URL and its components can be computed dynamically.

Connection example: Twilio API

The URL to connect with the Twilio API have the following form:

https://api.twilio.com/2010-04-01/Accounts/xxxxx

where xxxxx is the user account SID, and the following headers should be provided:

- Accept-Charset: utf-8- Accept: application/json- Authorization: Basic yyyyy

where yyyyy is the base 64 format of the user account SID and the user Authentication Token


https://api.twilio.com/2010-04-01/Accounts/xxxxx

- Accept-Charset: utf-8- Accept: application/json- Authorization: Basic yyyyy

The values of xxxxx and yyyyy can be statically typed on the URL and headers but, they must be updated every time the user credentials change.


A better approach is to use template parameters and Liquid Templates:

https://api.twilio.com/2010-04-01/Accounts/{{account_sid}}

- Accept-Charset: utf-8- Accept: application/json- Authorization: Basic {% base64 (account_sid + ':' + auth_token) %}

Defining the template parameters account_sid and auth_token Cenit computes dynamically the connection URL and its headers.

Webhooks example: Twilio API

The Twilio connection is just the base URL for the actions of the Twilio API, and these way is how occurs almost in every API.

It is possible the same URL to indicate different actions depending on the HTTP method, for example

https://api.twilio.com/2010-04-01/Accounts/xxxxx/Messages.json

send messages using the POST method but retrieve messages when using GET.

All those actions are defined as Webhooks.

Webhooks example: Twilio API

So a webhook is basically a path that completes the connection URL, and HTTP method and can define also a set of headers, parameters and template parameters.

The webhook path of the Twilio API will be:

- Messages.json by GET list the messages.

- Messages.json by POST send a message.

- Messages/{{id}}.json by GET retrieve a message with a SID.

Back to Flow

Since the webhook defines the action the flow will submit to the end-point then the webhook is primary over connection.

It is possible to submit the same action to several end-points, so the connections are not specified directly but through a connection role.

Connection Roles

A connection role is a relation between a set of connections and a set of webhooks indicating that every webhook in the set can be applied to every connection also in the set:

www.store1.com/api/v1

www.store2.com/api/2015

www.store3.com/2015

Connection Role

POST order

GET order

PUT order

Back to Flow, again

If the connection role is not defined then Cenit look for any connection from which it is possible to reach the webhook through a connection role.

If the connection role is supplied the Cenit only look for the associated connections to the connection role.

Back to Flow, againIf the connection role is not defined then Cenit look for any connection from which it is possible to reach the webhook through a connection role.

If the connection role is supplied then Cenit only look for the associated connections to the connection role.

Export Flows

If the flow translator is of type export it is possible to process the request response with a response translator.

Response translators are of type import and may require a response data type if they do not define one.

Response translators may create other records which may fire new event that trigger other flow processing…

Export Flows

If the flow translator is of type export it is possible to process the request response with a response translator.

Response translators are of type import and may require a response data type if they do not define one.

Response translators may create other records which may fire other events that trigger other flow processing…

CenitHubChapter 4

Flows, Connections & Webhooks

cenithub presentations | 4- flows, connections & webhooks

Data & Analytics