Example: Multicontext with a Time Trigger
Last updated
Last updated
This example illustrates the creation of a multi-context flow from a time trigger. Contexts are internally programmed from a flow variable.
In this example, we present a scenario of an integration between a Web System that provides weather information and a Postgres database. The weather information is obtained recurrently through a time trigger. At each reading, we also record the relevant information in a database so that it can be accessed later.
The reading of the weather information requires the specification of the locality about which the current data will be provided. In addition, it's necessary to provide an access token for the API to work correctly.
At first, we will do a single-context (conventional) flow that retrieves the data from a single location and stores it in a single database. Next, we will extend the same flow so that we can read the weather information from multiple locations using distinct access accounts and store the information from each location in a distinct database. To do this, we will use the platform's multicontext tools.
Steps
Create the single-context version of the flow to start with, so that we can more easily validate that it works correctly. The monocontext version is just a conventional version of flow that works for only one context. After checking if this version is functional we will turn it into a multicontext version.
You can also start creating a multicontext flow from zero. This example starts from a single-context stream for didactic purposes.
The original flow we are going to work with looks like the one in the figure below:
Periodically the flow calls a Weather API and gets the weather information for a particular location. Then, a Database module stores the relevant information in a Postgres database.
The Weather API requires only two parameters. The first is the locality in which to look for information. We enter this parameter through a previously configured flow variable.
The data returned by the Weather API is stored in the Postgres Database.
This flow has a temporal trigger and receives no external information at its initialization. For this reason, the context information will be stored within the flow itself using a flow variable.
In the multicontext version this same flow will run multiple times, but each time it will use different city information, Weather API access keys, and database account information. To do this, we will create a context key that will allow us to identify this information. The context key can be any identifier that is unique. We can use a userid information such as sequential numbers like: 0001, 0002, 0003, etc.
Create a flow parameter of type array. You can name it userid_list and set its value to the list of userids that will define the contexts, such as:
["0001","0002","0003"]
We will execute the same procedure for each context. For this we will create a loop defining which part of the flow will be executed repeatedly.
Specify the newly created flow parameter userid_list as the control list. This way the loop will be executed once for each context key.
Insert "Context Finder" as shown in the image below:
"Context Finder" requires as a parameter the key of the context to be used. Enter the value of the element to be used in the module. This way we are passing the userid values defined in the flow parameter created earlier.
We need to indicate which variables will change according to the "Context".
In the original flow there are two flow variables that will vary according to the context. Both are used as parameters by the Weather API.
location
key_
We need to set them both to be defined by context. To do this, access the definition of these variables in "Context" > "Variables".
If you go to "Settings", note that they are under "Variables" in the "Context" tab.
You can't move a flow variable to the context variable
We need to indicate which accounts will change according to the "Context".
In the original flow there is only one account that will change according to the context. It is the Postgres Database access account.
Go to the Database module and select the option: "Do you want to use flow context within this component?".
Click "Next". You can test the module again and then click "Save".
Each context will access its own account. For this you need to set up individual accounts.
Access the accounts in Settings-> Connected accounts. Under "Manage connected account", select the "Database" option and under Database: POSTGRESQL. Create the database access accounts.
Each context corresponds to a set of variables and accounts that will be accessed when the context is identified. In this step we create the contexts and assign a key to locate them.
In the main Flow editing panel, click on "Context". Initially only the Default context is present. Let's create the additional contexts for our example.
Click "Add new context". Specify a name for the first context, such as "User 01" and assign a value to the key. This is the value that will be searched by "Context Finder" to identify the context. Enter the value 0001 and click "Save".
Repeat the operation to create context User 02 with key 0002 and context User 03 with key 0003.
Set variable values and assign accounts for each context.
With the contexts created, you can edit their variables and define the accounts that each context should use. Click the pencil in the User 01 context to edit its values. Notice that in the Variables tab you have access to set the location and key_ parameters for this context. Click the pencil next to each of the parameters and set their values.
In the "Connected Accounts" tab you see all modules that require context accounts. In this example there is only the Postgres Database module that requires the definition of an account. Click the account selector and specify one of the Database accounts that you created earlier, in this example the User 01 DB account was selected. Save and close it to return to context editing.
Repeat the edit of parameters and accounts for the remaining contexts. In this example we use the information in the table below for the configuration. You will need to use your own access keys to configure the key_ variable for Weather API access.
Context
key
location
key_
account
User 01
0001
Sao Paulo
1f4efae6226c4e04a81140559220607
User 01 DB
User 02
0001
New York
f2fc5cb46fb74fe9b9d142517220607
User 02 DB
User 03
0003
Tokyo
8d91cdcb8c373805981143223220607
User 03 DB
You can verify the correct functioning of the flow through the logs available in the platform.
Activate the flow and click "Manual execution". Wait for the execution to finish and check the logs. Notice that the "Context Finder" finds the context information each time the flow goes through the loop.
Next Steps
Create a flow that gets the context key from external information.
The r is triggered every 15 minutes.
The second parameter is an authentication key to access the Weather API. Access to the API is public but requires prior registration on the where the key is provided to be used as authentication.
Insert the tool modules as shown in the diagram below. We will read the weather data and write it to the database for each context.
