Table Type: API

Situation

Sometimes we need to work with external data in our applications.

In this case we have one, maybe two options:

1. Create a table and a process flow with an HTTP connector to keep the data in sync.
2. Create a view with a template that runs a CLR function which calls an API.

Both of these options aren't perfect.

With option 1 I’m saving data in the database which I don't want to manage, I need to setup a process flow to call the API & I need to write a procedure to merge the data. 

With option 2 I'm introducing an extra technology into my project with the risk of creating legacy software. This is for instance a problem on most Azure SQL databases.

Solution

I would like to suggest a extra table type, ‘API’, to offer a nice and easy solution for all Thinkwise developers.

For this table type to function properly we need to include two extra options in the SF:

1. We can declare the columns as normal but should include a mapping of every column to the output of the API.
2. We need to the declare the consumption of the API, this can be done the same way as the input of the HTTP connector.

If I’m not mistaking team blue and orange offer a similar solution, so why shouldn’t we?