Construir
Señales y encadenamiento de workflows
Dos formas de hacer que un workflow inicie otro: lanzar una señal que escuchan tantos workflows como quieras, o llamar a un workflow concreto. En ambas, quien llama no espera el resultado.
Cuál usar
Enlace a esta sección: Cuál usar| Señal | Disparar workflow | |
|---|---|---|
| Quién inicia | Todos los workflows Live que escuchan la señal. | Un workflow a tu elección. |
| Contrato | La señal declara sus datos una sola vez; quien la emite y quienes la escuchan los comparten. | El formulario propio del destino, que rellena quien llama. |
| ¿El destino debe estar en Live? | Sí: debe estar live, publicado y escuchando. | No, pero tiene que haberse publicado al menos una vez: se ejecuta la versión publicada. Un workflow pausado todavía se puede llamar. |
| Destinos | Workflows con el trigger de señal. | Workflows con el trigger de ejecución manual o "Desde otro workflow". |
| Sin oyentes | No es un error: no pasa nada. | n/a |
Un administrador define las señales en «Señales de workflows» (en los ajustes de IA, Workflows). Una señal tiene un nombre, una descripción y los datos que viajan con ella: campos de tipo texto, número, sí/no o fecha, como un formulario pequeño. Los campos de otros tipos no se pueden crear en esa pantalla, y al editar una señal que ya los tiene se eliminan.
- Para lanzarla, añade el «Lanzar una señal» paso (la paleta muestra cada señal activa como una entrada ya preparada) y rellena los datos. Los datos se comprueban con la definición actual de la señal, así que un error aparece en el workflow que la lanza.
- Para escuchar, elige el trigger Señal y escoge la señal. El oyente guarda una copia congelada de la definición de datos de la señal cuando la eliges, y sus variables salen de esa copia.
- Se crea una ejecución en cola por cada workflow oyente que está live y publicado. Cero oyentes no es un problema.
- Renombrar una señal no rompe nada: los workflows se refieren a ella por id. Una señal nunca se elimina, solo se archiva. Una señal archivada no se puede lanzar ni elegir; sus oyentes existentes siguen publicados, pero los workflows que la lanzan fallan hasta que se restaure.
- La tabla de señales muestra cuántos workflows escuchan cada una, contando también los que no están en Live.
Cambiar una señal puede romper a quienes la emiten y a quienes la escuchan
Si añades un campo a una señal, quienes la emiten y no lo rellenan empiezan a fallar en cuanto se ejecutan, porque los datos se comprueban con la definición actual de la señal. Los listeners publicados antes siguen validando con la copia que congelaron, así que siguen funcionando y no ven el campo nuevo hasta que los vuelvas a publicar. Si quitas o cambias un campo, un listener falla solo cuando un emisor publicado después del cambio envía datos con la forma nueva, con "los datos de la señal no coinciden con los campos declarados". Abre y vuelve a publicar todos los listeners después de cambiar una señal.
Disparar workflow
Enlace a esta sección: Disparar workflow- El «Disparar workflow» paso inicia un workflow manual, o uno cuyo trigger es "Desde otro workflow", con los valores que le des. Devuelve el id y el estado de la nueva ejecución (
queued). - No espera a esa ejecución y no puede leer su resultado. Si el primer workflow necesita una respuesta, haz que el segundo lance una señal de vuelta.
- El paso es para administradores: se ejecuta con los permisos del creador y falla si el creador ya no es administrador.
- Elegir como destino cualquier otro tipo de workflow responde 409 cuando empieza la ejecución.
El límite que detiene los bucles
Enlace a esta sección: El límite que detiene los buclesUna cadena de runs se corta a los diez saltos. La cuenta es común a las tres formas en que un run puede iniciar otro: lanzar una señal, disparar un workflow y un cambio que hace un workflow y que dispara un evento de otro.
| Qué inicia el siguiente salto | Cuando se supera el límite |
|---|---|
| «Lanzar una señal» | El paso falla: "the limit of 10 workflows chained by signals was reached". |
| «Disparar workflow» | El paso falla: "the limit of 10 chained workflows was reached". |
| Un cambio que dispara un evento | El evento se registra como ignorado, no como fallido, y no se pone en cola ninguna ejecución. |
- La profundidad se guarda donde el autor de un workflow no puede falsificarla.
- Un workflow nunca se inicia por un evento que haya causado uno de los workflows de su propia cadena, así que A dispara B dispara A se detiene al volver, antes del límite.
- Un workflow aún puede llamarse a sí mismo, o dos workflows llamarse entre sí, hasta que el límite los detiene. El límite es la única protección.
Páginas relacionadas
Enlace a esta sección: Páginas relacionadasConstruir
Triggers
Un trigger decide cuándo se ejecuta un workflow. Cada workflow tiene exactamente uno, y puedes cambiarlo en el editor en cualquier momento (hasta que publiques, nada cambia para las ejecuciones).
Ejecutar
Límites y créditos
El motor aplica cada uno de los límites siguientes. La última columna dice qué ocurre cuando lo alcanzas, porque esa suele ser la pregunta.
Construir
Pasos
Los pasos se ejecutan en orden, uno tras otro. Cada uno puede leer lo que produjeron el trigger y los pasos anteriores, y cada uno puede publicar un valor para los pasos siguientes.
¿Te ha resultado útil esta página?