> For the complete documentation index, see [llms.txt](https://docs.skyone.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skyone.cloud/espanol/skyone-studio/integraciones/operaciones-de-datos/reglas-de-parametrizacion.md). # 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. {% hint style="info" %} En el caso de loops, solo los valores de la última ejecución están disponibles. {% endhint %} *** #### 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" }` {% hint style="info" %} Para que las strings del objeto final tengan comillas, es necesario incluirlas en la definición del Body. Skyone Studio no agrega comillas automáticamente. {% endhint %} *** **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:** ```json { "result" : { "resp_body" : { "city_id" : "0987654321" } } } ``` {% hint style="info" %} **Skyone Studio** inserta una propiedad llamada result como base de los datos referenciados. {% endhint %} {% hint style="info" %} Puedes pasar múltiples parámetros a un Data Transformation. Solo debes crear un DATA utilizando un objeto con múltiples propiedades, cada una referenciando un parámetro. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.skyone.cloud/espanol/skyone-studio/integraciones/operaciones-de-datos/reglas-de-parametrizacion.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.