Reglas de Parametrización
Parametrización en Skyone Studio
La mayor parte de las llamadas utilizadas en módulos de conectores están parametrizadas. De esta manera, puedes utilizar valores obtenidos en módulos anteriores de un flujo como parámetros de ejecución para los módulos subsecuentes. La parametrización y sustitución de valores sigue algunas reglas.
Parámetros
Cuando especificamos un módulo, definimos los parámetros externos que este recibirá. Durante la construcción de un flujo, definimos cómo se llenarán esos parámetros utilizando valores que ya están disponibles hasta el momento de la ejecución del módulo.
Al construir un módulo, definimos los parámetros que deben ser llenados con valores proporcionados en tiempo de ejecución para su correcta ejecución. Por ejemplo, podemos definir un parámetro de identificador de ciudad para un módulo REST que necesite ese valor en la llamada de la URL. Esto se hace colocando un marcador de parámetro en la posición de la URL que debe recibirlo. En el ejemplo siguiente, “Size” es un parámetro. Al hacer clic sobre él, es posible visualizar los detalles del parámetro.
Durante la ejecución de un flujo, Skyone Studio reemplaza ese marcador por el dato especificado en la construcción del flujo. Este dato debe estar disponible en el plan de datos de ejecución del flujo. Dicho plan de datos está compuesto por todos los datos previamente obtenidos en módulos anteriores, además de las variables definidas en tiempo de configuración.
Al construir un flujo, definimos qué datos se utilizarán para cada parámetro necesario en cada módulo.
En el ejemplo anterior, podemos definir que el valor de CityId en un flujo determinado será proporcionado dentro del body del webhook que inicializa el flujo. Al configurar este módulo en un flujo, necesitamos determinar qué datos se mapearán a cada parámetro.
Observa que este módulo tiene dos parámetros a configurar: User-Key y CityId. Aparecen a la derecha bajo “Configuración de Parámetros”. Puedes especificar un parámetro de forma estática, como se muestra en User-Key. Para ello, simplemente ingresa el valor deseado en el parámetro.
Sin embargo, es más común utilizar valores dinámicos que se determinan en cada ejecución del flujo, como se ilustra para el parámetro CityId. En este ejemplo, siempre se llenará en tiempo de ejecución con el valor city_id que viene en el body del webhook que inicia el flujo.
Observa que, a la izquierda de la pantalla de configuración, se muestran las variables (Parámetros de Flujo o Flow Parameters), así como todos los módulos ya ejecutados y los datos recibidos en cada módulo. En este caso, vemos el Gatilho Webhook y tenemos acceso al contenido de su body, donde se encuentra la propiedad city_id que contiene el valor deseado.
A medida que el flujo se ejecuta, el plan de datos va recibiendo todos los datos que los módulos obtienen. Estos se vuelven inmediatamente disponibles para ser consumidos por los parámetros de los módulos subsecuentes.
Observa que iniciamos un flujo únicamente con las variables (Parámetros de Flujo), que son valores determinados por el operador en tiempo de configuración. Además, el propio evento externo puede aportar información, como es el caso de un webhook o de una llamada de API. Todos estos valores están disponibles en el plan de datos de ejecución.
El primer módulo después del Gatilho dispone de las variables (Parámetros de Flujo) y de los posibles datos que el Gatilho trae para ser utilizados como parámetros. Este módulo puede realizar manipulaciones de datos y eventualmente interactuar con algún sistema externo, obteniendo más datos durante su ejecución.
El segundo módulo en la secuencia de ejecución puede utilizar todos los datos obtenidos por el flujo hasta ese momento, lo que incluye las variables (Parámetros de Flujo), la información del Gatilho, así como todos los datos obtenidos por el Módulo 01. Este segundo módulo, a su vez, puede interactuar con sistemas externos y recibir datos adicionales que podrán ser utilizados por todos los módulos subsecuentes. Este proceso se repite para todos los módulos de un flujo.
Marcado de Parámetros
Los parámetros pueden especificarse en diversas llamadas de módulos. Podemos tener una URL de una solicitud REST que utiliza un parámetro, así como una query a una base de datos que también esté parametrizada.
Para identificar un parámetro en Skyone Studio, se utilizan símbolos específicos que funcionan como marcadores de inicio y fin. El contenido entre estos símbolos identifica el nombre del parámetro.
Ejemplo:
<>CityId</>
En este caso, el nombre del parámetro es CityId, y los símbolos de marcado son los signos de mayor y menor. Cada vez que Skyone Studio encuentra esta marca, reemplaza los símbolos por el valor actual del parámetro.
Por ejemplo, en la ruta de solicitud REST a continuación encontramos la especificación de este parámetro:
Cities/<>CityId</>
Para ejecutar este módulo, Skyone Studio sustituirá el marcador del parámetro por el valor correspondiente. Por ejemplo, si el valor es 999999, la ruta utilizada será:
Cities/999999
Tipos de Marcado de Parámetros y Datos
Básicamente existen tres tipos de marcado que identifican parámetros y datos en Skyone Studio.
[Tabla de tipos de marcado]
Sustitución de Parámetros
Es importante observar cómo los marcadores de parámetros son reemplazados por los datos durante la ejecución de un flujo. El producto utiliza únicamente el contenido del dato especificado para llenar la posición del parámetro.
Ejemplos:
Parámetro string en URL
Parameter Name: CityId
Parameter Type: string
Endpoint:
baseURL/Cities/<>CityId</>Data: []GXpfha3Z : city_id[/]
Data Type: string
Data Content: “XXXXXXX”
Replacement:
baseURL/Cities/XXXXXXX
Parámetro string en body JSON
Parameter: CityId
Parameter Type: string
Body:
{ "city" : "<>CityId</>" }Data: []GXpfha3Z : city_id[/]
Data Type: string
Data Content: “XXXXXXX”
Replacement:
{ "city" : "XXXXXXX" }
Parámetro object en Data Transformation
Parameter Name: DATA
DATA Example:
{ "resp_body" : {}trigger : body{/} }Data: {}trigger : body{/}
Data Type: object
Data Content:
{ "city_id":"0987654321" }
Replacement:
Last updated