Desencadenantes

Descubre cómo utilizar los desencadenantes para crear lógica en las aplicaciones sin escribir código.

En este artículo aprenderás:

• Los comandos de los desencadenantes, la lógica y el comportamiento de ejecución
• Prácticas recomendadas para crear y organizar desencadenantes
• Casos de uso habituales

Los desencadenantes te permiten añadir lógica a tu aplicación. Puedes utilizarlos para interactuar con dispositivos, enviar alertas, escribir datos, comunicarte con sistemas de backend y mucho más, todo ello sin escribir ni una sola línea de código.

Entre los casos de uso habituales de los desencadenantes se incluyen:

• Navegar dentro de una aplicación: utiliza una transición para pasar a un paso diferente.
• Finalizar una aplicación: registrar los metadatos de la aplicación.
• Ejecutar una función de conector para acceder a un sistema de backend: utiliza los conectores para que Tulip pueda interactuar con sistemas de terceros y ejecuta una función de conector mediante un disparador.
• Enviar alertas: envía alertas por correo electrónico o SMS desde una aplicación a un administrador. Estos mensajes pueden incluir imágenes, información sobre el estado del proceso u otra información relevante.
• Almacenar datos: almacena los datos de entrada de una aplicación en variables o tablas.
• Utilizar un dispositivo: para los operadores que utilizan ambas manos durante un proceso, añade un disparador para un evento del dispositivo, como un pedal, para avanzar al siguiente paso.

¿Cómo funcionan los desencadenantes?

Lógica

Los disparadores utilizan una estructura lógica «cuando, si, entonces, si no »:

• cuando «se registra un evento en Tulip»
• entonces «realizar acción» o «efectuar transición».

Los desencadenantes también pueden contener lógica condicional:

• cuando «se registra un evento en Tulip»
• si «se cumple la condición»
• entonces «realizar una acción»
• en caso contrario, «realizar una acción diferente»

Más información sobre la lógica condicional de los desencadenantes aquí.

Los desencadenantes se agrupan en un y constan de una acción y condiciones.

Los desencadenantes pueden ser sencillos, como en el ejemplo siguiente:

Cuando se pulsa un botón, se pasa al siguiente paso.

O bien, los desencadenantes pueden ser más complejos, como el escaneo de un código de barras que consulta una base de datos de backend para devolver información del pedido como variable.

Cuando el escáner de códigos de barras envía datos a la estación actual, una API Call (ejecutada a través de una función de conector) recupera los detalles del pedido de una base de datos externa y almacena el valor en una variable. A continuación, el desencadenador pasa al siguiente paso.

Tipos de comandos

Puedes utilizar dos tipos de comandos en un disparador:

1. Acción: un cambio en la aplicación que no está relacionado con el cambio de pasos (p. ej., mostrar un mensaje de error, enviar un correo electrónico, capturar una captura de pantalla de la aplicación).
2. Transición: un evento de navegación dentro de la propia aplicación (p. ej., pasar al siguiente paso, completar una aplicación, cancelar una aplicación). Las transiciones pueden hacer que se activen otros desencadenantes (es decir, que se inicien). Por ejemplo, puedes crear un desencadenante a nivel de aplicación que se active cada vez que se complete la aplicación.

Cola de desencadenantes

Los (p. ej., hacer clic en un botón) añaden activadores a una secuencial de un solo hilo para su ejecución en el Tulip Player.

La afecta a: 1. Funciones: * Las funciones se incluyen en la cola de desencadenantes. 2. Widgets personalizados: * La ejecución de la lógica en un widget personalizado puede afectar a la cola de desencadenantes

Orden de ejecución

Los «Triggers» se ejecutan en serie y en orden según el « Trigger Event » (es decir, clic en un botón, temporizador, selección de una fila de la tabla).

Los disparadores se ejecutan de forma secuencial, lo que significa que el primer disparador de la serie debe completarse antes de que el segundo comience a ejecutarse. Este orden de ejecución de los disparadores se conoce como la cola de disparadores.

La cola de disparadores es independiente de otras tareas dentro de una aplicación, como las interacciones con variables (p. ej., campos de texto, casillas de selección), los widgets personalizados y el código JavaScript de los widgets personalizados.

¿Cómo se utilizan los valores de entrada en los desencadenantes?

Los valores de entrada (es decir, las variables) se pasan por referencia a los desencadenantes.

Los desencadenantes hacen referencia al valor de entrada de una variable en el momento de la ejecución del desencadenante. Si el valor de entrada cambia antes de que se ejecute un desencadenante, este hará referencia al valor más actualizado.

Las variables son globales para una aplicación, lo que hace que puedan ser modificadas por otra lógica de la aplicación.

:

¿Cuándo se cancelan los desencadenadores?

Los desencadenantes de la cola de desencadenantes se cancelan —y, por lo tanto, no se ejecutan— cuando:

1. Un disparador se pone en cola tras una transición: cuandose ejecuta una transición (por ejemplo, «Siguiente», «Finalizar aplicación», «Ir al paso por nombre», etc.), se cancelan todos los disparadores que queden en la cola.
2. Se fuerza el cierre del Tulip Player: siun operador fuerza el cierre del Player (por ejemplo, si una aplicación no responde), se cancelan las acciones restantes de cualquier disparador en ejecución y todos los disparadores restantes de la cola.

Gestión de errores

Se producirán errores en los desencadenantes y la consiguiente cancelación en los siguientes casos:

1. Error en la acción del disparador
2. Tiempo de espera del desencadenante agotado

Error en la acción del disparador

Cuando se produce un error en una acción de un desencadenador, las acciones restantes de dicho desencadenador se omiten o se cancelan:

Tras un error, de forma predeterminada, los desencadenantes restantes en la cola y en el evento del desencadenante no se ejecutarán para los siguientes desencadenantes a nivel de aplicación y de paso:* Inicio de la aplicación* Finalización de la aplicación* Cancelación de la aplicación* Al entrar en un paso* Al salir de un paso

Para todos los demás tipos de desencadenantes (por ejemplo, «Al pulsar un botón»), la opción «Detener los desencadenantes restantes en caso de error» está desactivada de forma predeterminada.

Tiempo de espera del desencadenador

Si un desencadenador agota el tiempo de espera (véase «Tiempos de espera de los desencadenadores»), se cancelarán todos los desencadenadores restantes de la cola.

Comportamiento técnico

Tiempo de ejecución del disparador

• Los desencadenantes se ejecutan de forma secuencial en un único tiempo de ejecución. El tiempo de ejecución de un desencadenante es el periodo durante el cual este se está ejecutando activamente en Tulip.
• Los desencadenantes nunca se ejecutan en paralelo ni en segundo plano respecto a otros desencadenantes. Un nuevo desencadenante no puede comenzar a ejecutarse hasta que haya finalizado el desencadenante actual que se está ejecutando.
• Los operadores pueden seguir interactuando con la aplicación (por ejemplo, hacer clic en botones o interactuar con tablas) mientras se ejecuta un disparador. Estos clics en botones y otros eventos de disparador añadirán nuevos disparadores a la cola de disparadores.

Tiempos de espera de los desencadenantes: actualizado a partir de LTS15 / r332

El tiempo de espera predeterminado de un disparador es de 10 minutos; transcurrido este tiempo, el disparador y cualquier acción restante se cancelarán, y se cancelarán también todos los demás disparadores de la cola.

El tiempo de espera de 10 minutos se aplica al Trigger Event. Por ejemplo, si al hacer clic en un botón se activan 5 desencadenantes, los 5 desencadenantes de la cola de desencadenantes y sus respectivas acciones deben ejecutarse en el plazo de 10 minutos.

Tras 30 segundos de ejecución del disparador, la aplicación muestra el siguiente mensaje al operador:

Tras 100 segundos de tiempo de ejecución del disparador, la aplicación muestra el siguiente mensaje al operador:

Transcurridos 10 minutos, el disparador se cancela y la aplicación muestra el siguiente mensaje de error:

Configuración opcional del tiempo de espera

Edita la configuración del tiempo de espera de una instancia mediante los métodos que se indican a continuación:

1. Tulip puede activar o desactivar una configuración que permite a los operadores cancelar manualmente un disparador de larga duración tras los primeros 100 segundos. Ponte en contacto con el servicio de asistencia de Tulip para activar esta función.

2. El servicio de asistencia de Tulip puede reducir o aumentar el periodo de tiempo de espera. Ten en cuenta que Tulip recomienda el periodo de tiempo de espera de 10 minutos como punto de partida, para aumentar la probabilidad de que tu lógica se ejecute hasta el final. Si un disparador tarda sistemáticamente más de unos minutos en ejecutarse, ten en cuenta lo siguiente:

   • Simplificar la lógica del disparador para mejorar la experiencia del operador y reducir la probabilidad de que el disparador falle.
   • Si es posible, inicie una automatización en segundo plano para descargar la ejecución de la lógica y evitar que se bloquee el trabajo continuo del operador.
   • Revisar y optimizar cualquier dependencia de sistemas de terceros en la lógica del disparador (por ejemplo, funciones de conector lentas o uso de una API no óptima).

Acciones sobre registros de tabla

Creación de un registro de tabla

Para la creación de un nuevo registro de tabla, la práctica recomendada es hacer seguir inmediatamente a la acción «Registro de tabla / Crear registro» con las acciones de manipulación de datos correspondientes para rellenar las demás columnas del registro de tabla recién creado.

Si hay otras acciones entre la acción «Registro de tabla / Crear registro» y las acciones para rellenar las demás columnas, la generación de ese registro de tabla aparecerá como eventos separados en el widget del historial de registros.

Creación de un registro de tabla: a partir de LTS15 / r332

A partir de LTS15, las acciones secuenciales de tabla «Registro de tabla / Crear registro» y «Manipulación de datos / Almacenar» se agruparán para el mismo registro. Esto significa que las acciones «Crear» y «Manipulación de datos» de un disparador se ejecutan en una sola transacción.

Las acciones «Crear registro» y «Manipulación de datos / Almacenar» no se agruparán en una sola transacción si hay otras acciones entre ellas (por ejemplo, manipulaciones de datos en variables u otros registros de tabla, funciones de conector, etc.).

En los siguientes ejemplos de desencadenadores, la acción «Crear registro» y las acciones de «Manipulación de datos / Almacenar» se agruparán y, o bien se ejecutarán todas con éxito, o bien fallarán todas. Si todas las acciones fallan, se volverán a intentar juntas mediante reintentos resilientes.

Ejemplo 1: Creación secuencial y manipulaciones de datos en el mismo registro de tabla. En LTS15, todas estas acciones se realizarían correctamente o fallarían por completo, pero no así en versiones anteriores a LTS12.

Ejemplo 2: Creación secuencial y manipulaciones de datos en el mismo registro de tabla, seguidas de una acción de función de conector. Las acciones de «Creación de registro de tabla» y «Manipulación de datos» se agruparían en LTS15. La acción de función de conector podría fallar independientemente de que las acciones de la tabla se completaran con éxito.

En el siguiente disparador, las acciones de «Manipulación de datos» y «Almacenar» se producen en dos registros de tabla diferentes, por lo que las acciones no se agruparán en una única transacción.

Ejemplo 3: «Registro de tabla / Crear» y «Manipulación de datos / Almacenar» en el mismo registro de tabla, separadas por otra acción de «Manipulación de datos». Estasacciones no se agruparán en una única transacción.

En el siguiente disparador, las acciones «Registro de tabla» y «Manipulación de datos / Almacenar» no se agruparán porque los metadatos del registro de tabla creado en la acción anterior se utilizan como datos de entrada de la acción «Manipulación de datos / Almacenar».

Ejemplo 4: Crear y actualizar leyendo datos de sí mismo. Estas acciones no se agruparán en una única transacción.

Cuando se utiliza una agregación en una acción de actualización de tabla agrupada, el valor de la agregación se toma antes de que se produzca la actualización. El valor de la agregación no reflejará la actualización del registro de tabla agrupado.

Ejemplo 5: Crear y actualizar con agregaciones. Estas acciones se agruparán, y el valor de la agregación se toma antes de que se produzca la acción de creación.

Actualización de un registro de tabla

Las acciones secuenciales de manipulación de datos sobre el mismo registro de tabla se agrupan para ejecutarse en una sola solicitud de red, por lo que todas se realizan a la vez

Las acciones de activación relacionadas con registros de tabla se agrupan en función de su tipo y orden. Las acciones de almacenamiento que tienen la misma ubicación de almacenamiento se agrupan en una sola solicitud de red. Por el contrario, acciones como «Cargar registro» o «Crear registro» se tratan como transacciones individuales.

Para obtener el mejor rendimiento, recomendamos agrupar las actualizaciones del mismo registro, es decir, no intercalar las actualizaciones de un mismo registro con otras acciones relacionadas con tablas o datos.

Ejemplo 1: Actualizaciones secuenciales del mismo registro. Estasacciones se agruparán en una sola transacción:

Ejemplo 2: Actualizaciones del mismo registro separadas por otras acciones. Estas acciones no se agruparán, ya que los registros de la misma tabla no son secuenciales:

En el siguiente disparador, las acciones de manipulación de datos y de almacenamiento se producen en dos registros de la tabla diferentes y, por lo tanto, las acciones no se agruparán en una única transacción.

Ejemplo 3: Actualizaciones de dos registros diferentes. Estas acciones no se agruparán en una única transacción.

Cuando se utiliza una agregación en una acción de actualización de tabla agrupada, el valor de la agregación se calcula antes de que se produzca la actualización. El valor de la agregación no reflejará la actualización del registro de la tabla agrupada.

Ejemplo 4: Actualizaciones que incluyen agregaciones. Estas acciones se agruparán, lo que significa que el valor de la agregación se calcula antes de que se produzca la actualización.

Reintentos de disparadores (acciones de tabla): novedad a partir de LTS15 / r332

Los desencadenadores solo reintentan acciones de tabla (por ejemplo, escrituras de datos en tablas, actualizaciones de datos en tablas, interacciones con tablas, etc.).

Durante los 10 minutos de ejecución del disparador, si falla una sola acción de tabla, se reintentará durante un máximo de 2 minutos. Si la acción no se ejecuta tras 2 minutos, se cancelarán las acciones y los disparadores restantes de la cola del disparador.

Para que un disparador sea resistente a fallos de red, asegúrate de que sus acciones incluyan únicamente interacciones con tablas y actualizaciones de datos. Consulta «Acciones de registros de tabla» para obtener orientación sobre las acciones de tabla resistentes a fallos.

Los reintentos de las acciones del disparador no duplicarán el resultado si la acción se ejecuta accidentalmente dos veces. Esto garantiza que una acción de tabla no escriba múltiples copias de los mismos datos.

Límites y tiempos de espera

Tipos de disparadores

Existen tres tipos de desencadenantes:

Desencadenantes a nivel de aplicación

Puedes aplicar desencadenantes a nivel de aplicación a los siguientes eventos:

• Inicio de la aplicación
• Finalización de la aplicación
• Cancelación de la aplicación

Accede a los desencadenantes a nivel de aplicación desde la pestaña «Aplicación».

Más información sobre los activadores a nivel de aplicación aquí.

Desencadenantes a nivel de paso

Puedes aplicar desencadenantes a nivel de paso a los siguientes eventos:

• A intervalos de tiempo regulares («disparos por tiempo»)
• Cuando hay una entrada procedente de una máquina o un dispositivo («máquinas y dispositivos»)
• Cuando se abre el paso
• Cuando se cierra el paso

Accede a los desencadenantes a nivel de paso desde la pestaña «Paso».

Más información sobre los desencadenantes a nivel de paso disponible aquí

Desencadenantes de widgets

Los desencadenantes de widgets se activan al pulsar un botón. Puede haber varios desencadenantes de botones en un paso que se activan cuando un operador pulsa el botón correspondiente en el reproductor Tulip.

Selecciona el widget deseado y, a continuación, accede a los desencadenantes de widgets desde la pestaña «Widget».

Más información sobre los desencadenantes de widgets aquí.

Crear un activador

1. En el , haz clic en + en la sección «Desencadenantes ». Se abrirá el editor de desencadenantes.
2. Asigna un nombre al activador para identificar su función en la aplicación. También puedes incluir una descripción con más detalles.

Prácticas recomendadas

• **Configura los desencadenantes para que se adapten a los errores.**Los desencadenantes deben configurarse para continuar o detenerse en caso de error. Un desencadenante puede dar error debido a entradas no válidas, un error de ejecución o un fallo en la función de un conector o en un intento de escritura en una tabla.
• Cuando un desencadenador está configurado para continuar, el desencadenador que ha dado error se detendrá, pero el siguiente desencadenador seguirá adelante
• Cuando un disparador está configurado para detenerse, los demás disparadores del evento de disparador se cancelarán.

• Evita tener desencadenadores de larga duración en un paso con widgets interactivos. Los widgetscambian visualmente de estado inmediatamente tras la interacción. Aunque el operador vea que la acción se produce de inmediato en el widget, la lógica puede ejecutarse con un ligero retraso debido a una red lenta o a un conector de larga duración.
• Forma a los operadores para que esperen tras hacer clic en una transición (p. ej., «Siguiente paso»). En un paso, los desencadenantes en cola tras una transición no se ejecutarán. Si un operador interactúa con un widget que tiene una transición, permanecerá en el paso hasta que se ejecute la transición. Por ejemplo, si el operador hace clic en «Siguiente paso» y luego activa otro desencadenador mientras espera, el desencadenador restante tras la transición no se ejecutará.
• Ejecute los conectores de larga duración y las actualizaciones de datos en pasos separados. Las interacciones con datos sensibles no deben realizarse en el mismo paso que la lógica de los conectores de larga duración. En caso de que un operador interactúe con el paso tras hacer clic en un disparador o una transición de larga duración, existe el riesgo de que no se almacenen datos críticos.
• Asegúrese de que las variables tengan una única entrada por cada paso. Las variablesno deben compartirse con lógicas de entrada que compitan entre sí (es decir, varios botones en una aplicación que actualicen la misma variable) para evitar condiciones de carrera. Por ejemplo, un desencadenante captura el valor actual de una variable. Si el valor de la variable cambia antes de que un desencadenante lo capture, los datos serán incorrectos.

Más información

• Lista de acciones de desencadenantes y transiciones
• Lógica condicional de los desencadenantes
• Prácticas recomendadas para aplicaciones de alto rendimiento

{{snippet.¿Has encontrado lo que buscabas?}}