Parameterization rules
Parameterization in Skyone Studio
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.
Parameters
When specifying a module, we define the external parameters it will receive. During the construction of a flow, we determine how these parameters will be populated by using values that are already available at the time the module executes.
When building a module, we define parameters that must be filled with values provided at runtime for the module to execute correctly. For example, we might define a city identifier parameter for a REST module that requires this value in the URL call. This is done by placing a parameter placeholder in the position within the URL where the value should be inserted. In the example below, "Size" is a parameter. By clicking on it, you can view details about the parameter.
At flow runtime, Skyone Studio replaces the placeholder with the data specified during the flow's design. This data must be available in the flow’s execution data plan. The execution data plan consists of all data previously retrieved from earlier modules, as well as variables defined during the configuration phase.
When building a flow, you define which data will be used to populate each required parameter in every 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 Skyone 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:
<>CityId</>In this case, the name of the parameter is called CityId and the marking symbols are the major and minor signs. Every time that Skyone 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:
Cities/<>CityId</>To execute this module, Skyone Studio will replace the parameter placeholder with the value of the data to be used. For example, if this value is 999999, Skyone Studio will use the following path:
Cities/999999Parameter and Data Marking Types
There are basically three types of marking that identify parameters and data in Skyone Studio:
<>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 retrieved during a flow's runtime. Skyone Studio will replace the placeholder with the value of the data at the time of execution. The name of the data is a combination of the module’s identifier where 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. Skyone Studio 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:
baseURL/ Cities/XXXXXXXString parameter in JSON body
Parameter: CityId
Parameter Type: string
Body: { “city” : “<>CityId</>” }
Data: []GXpfha3Z : city_id[/]
Data Type: string
Data Content: “XXXXXXX”
Replacement:
{ “city” : “XXXXXXX” }Object parameter in Data Transformation
Parameter Name: DATA
DATA Example:
{ “resp_body” : {}trigger : body{/} }Data: {}trigger : body{/}
Data Type: object
Data Content:
{ "city_id":"0987654321" }Replacement:
{
“result” : {
"resp_body" : {
"city_id" : "0987654321"
}
}
} Last updated