Parameterization rules
Last updated
Last updated
Most of the calls used in connector modules are parameterized. This way you can use values from previous modules in a flow as execution parameters for subsequent modules. The parameterization and substitution of values follow a few rules.
When we specify a module, we define the external parameters that they will receive. During the flow construction, we define how these parameters will be filled using value that are already available by the module execution.
When building a module, we define parameters that should be filled with values that will be provided at runtime for its correct execution. For example, we can define a city identifier parameter for a REST module that requires this value when calling the URL. We do this by placing a parameter marker at the position in the URL that should receive it. In the example below, "Size" is a parameter. When you click it, you can view details about the parameter.
At runtime of a flow, the platform replaces this marker with the data specified when constructing the flow. This data must be available in the flow execution data plane. This data plane is composed of all the data previously obtained in the previous modules plus the flow the variables that are set at setup time.
When we build a flow, we define which data will be use for each parameter necessary in each module.
In the previous example, we can define that the value of CityId in a specific flow will be provided within of the body of the webhook that initializes the flow. When we are configuring this module in a flow, we need to determine which data will be mapped to which parameters. The screenshot below shows this configuration.
You will note that this module has two parameters to configure: User-Key and CityId. These are listed on the right side under Parameter settings. You can specify a statically parameter, as shown in User-Key. To do this, you should enter the needed value in the parameter.
However, it is more common to use dynamic values that are determined at each execution of the flow, as illustrated for the CityId parameter. In this example, it will always be filled at runtime with the city_id value that comes in the body of the webhook that initializes the flow. Take note that on the left of the configuration screen we see the variables (Flow Parameters) as well as all the modules already executed and the data received in each module. In this case, we see the Webhook Trigger and have access to the content of its body, which contains the city_id property that contains the needed value.
As the flow runs, the data plan receives all the data that the modules get. It becomes immediately available to be consumed by the parameters of subsequent modules.
Observe that we start a flow only with the variables (Flow Parameters), which are value determined by the operator at setup time. Also, the external event itself can provide information, as is the case with a webhook or an API call. All these values are available in the data plan of the execution.
The first module after the Trigger has the variables (Flow Parameters) and any data that the Trigger returns to be used as parameter. This module can make data manipulations and eventually interact with some external system and obtain more data during the execution.
The second module that comes in the execution sequence can use all data obtained by the flow so far, which includes the variables (Flow Parameters), the Trigger information, as well as all data obtained by Module 01. This second module in turn can interact with external systems and also receive additional data that can be used by all the modules in the sequence. This process can happen for all modules of a flow.
Parameter Marking
Parameters can be specified in various modules calls. We can have a URL of a REST request that uses a parameter, just as we can have a query to a database that is also parameterized.
To identify Flow Studio parameters we use especific symbols that work as start and end markers. The content between these symbols identifies the name of the parameter. Example:
In this case, the name of the parameter is called CityId and the marking symbols are the major and minor signs. Every time that Flow Studio finds this flag, it will replace these symbols with the current value of the parameter.
For example, in the REST request path bellow we find the specification of this parameter:
To execute this module, Integra.Sky will replace the marker of the parameter with its data value that should be use. For example, if this value is equal to 999999, the platform will use the next path:
Parameter and Data Marking Types
There are basically three types of marking that identify parameters and data in Integra.Sky:
<>parameter</>
Parameter: Parameter specification used during module construction. It's how we specify that certain values should be substituted for values provided at runtime.
{}module : parameter{/}
Execution Data: Data obtained at runtime from a flow. The platform will replace this marker with the value of the data at runtime. The data name is a composition between the identifier of the module in which it was generated and the name of the property.
[]module : parameter[/]
Variables These are values that the operator can define at setup time through the Flow Parameters. They are permanent variables and are therefore maintained between different executions of a flow. The Update Parameter module also allows a flow to directly change the value of a flow parameter.
Parameter Replacement
It’s important to observe how parameters markers are replaced by data during the execution of a flow. Integra.Sky uses only the contents of the specified data to fill the parameter position.
Examples:
String parameter in URL
Parameter Name: CityId
Parameter Type: string
Endpoint: baseURL/ Cities/<>CityId</>
Data: []GXpfha3Z : city_id[/]
Data Type: string
Data Content: “XXXXXXX”
Replacement:
String parameter in JSON body
Parameter: CityId
Parameter Type: string
Body: { “city” : “<>CityId</>” }
Data: []GXpfha3Z : city_id[/]
Data Type: string
Data Content: “XXXXXXX”
Replacement:
Object parameter in Data Transformation
Parameter Name: DATA
DATA Example:
Data: {}trigger : body{/}
Data Type: object
Data Content:
Replacement:
