Example: Multicontext with an API Gateway
Last updated
Last updated
This example shows how a multi-context flow can be produced from requests in an API Gateway. Data included in the request is used to inform the contexts.
Through a REST call set up in Integra's API Gateway, this integration aims to make weather data kept in a Postgres database accessible. The database created by Example Integration: Multicontext with Time Trigger will serve as our starting point.
This integration will initially only be able to access one database for a single user. Then the same integration will be expanded so that multiple users can access it by simply entering their userid. This will be the data we use to identify the context and with this Integra.Sky can access the correct database for each user.
Steps
Step by Step
This flow is activated by a request through the API Gateway. The Query String of the request must only contain the number of most recent samples that will be retrieved from the database. The response contains the samples as well as some average temperature and humidity data that were calculated by the platform itself.
Call to trigger the flow:
The user database's most recent 100 records are retrieved as a result of this call. Along with these statistics, the average temperature and humidity are also returned.
In this case, we will use a piece of information that comes in the API call itself to define what the context will be. To do this, we will change the Query String of the Trigger API to make it ready to accept the userid. This will be the variable used to define the context. Each userid will link to a particular database account.
With this modification, we will use external information to define the context that will be used.
"Context Finder" will use the context set variable (userid) to locate the database account that will be used to retrieve the weather records.
Context Finder should be inserted right after the API trigger so that it can use the information that comes in the trigger call to identify the context.
And we will indicate the userid information, which is inside the query string, as a context identification parameter.
Go back into the Postgres module configuration and select the "use context in this component" option.
By default, the platform will use the account that was already set up as the Default account.
Click on "Next". Select the context and run a test of the new configuration. As you had already run this flow in mono-context, the platform will use the original account as the default account.
Each of the contexts should have its own specific account associated with it.
Create the database accounts in Settings → Connected Accounts.
Create a context for each user that will access the system.
Select "Context" from the flow editing page. Add as many contexts as needed, and specify the value of the key associated with each context.
For each of the contexts, link the respective Postgres module account.
In Flow Context, edit each of the contexts. Select the Connected Accounts tab and select the respective account.
Enter the userid in the API call that calls the flow.
In your API calling software, specify the value of the userid. Use one of the values specified when creating the context.
Notice that you are now provided with two values for the execution of the flow. The value of n specifies the number of samples that will be retrieved and the value of userid specifies the context and therefore which database will be chosen.
You can see that we can identify the correct operation of Context Finder by the execution logs.
