Workflows: orquestación, versiones y ejecución
Objetivo y modelo
Un Workflow coordina tareas, sus dependencias y las decisiones que determinan el recorrido de una ejecución. Las Sessions enlazan transformaciones con su contexto; el Workflow establece cómo se combinan. El canvas muestra tareas y conectores, mientras que la configuración de la tarea permite revisar su comportamiento.
Separar Mapping, Session y Workflow facilita reutilización y gobierno, pero introduce referencias versionadas. Una versión publicada del Workflow debe evaluarse junto con las versiones de sus dependencias. Cambiar una definición aguas arriba no equivale a actualizar silenciosamente una ejecución ya publicada.
Requisitos
Necesita permisos de lectura y, para cambios, edición del Workflow. Publicar, ejecutar y administrar programaciones pueden requerir permisos adicionales. Prepare una Session publicada y un worker compatible antes de comprobar la ejecución.
Utilice un Domain y una Folder de laboratorio. En los nombres de objetos ejecutables, siga la validación del editor: letra inicial y caracteres alfanuméricos o guion bajo, dentro del límite mostrado. Evite reutilizar nombres operativos para ensayos.
Recorrido de diseño
- Abra Workflows y cree un Workflow de laboratorio.
- Revise nombre, Domain, Folder y alcance de compartición.
- Abra el editor y añada una tarea que consuma una Session preparada.
- Configure la tarea y sus dependencias. En un diseño con decisiones, compruebe que las ramas tengan condiciones complementarias y que cada destino esté conectado donde corresponde.
- Use los controles de canvas para seleccionar, mover, reorganizar y ajustar la vista.
- Valide el diseño, guarde el borrador y publique una versión cuando no queden problemas.
- Ejecute manualmente antes de añadir una programación periódica.
| Acción | Efecto esperado |
|---|---|
| Save draft | Conserva la definición editable |
| Publish | Establece una versión para consumo autorizado |
| Run | Inicia un intento de ejecución |
| Auto arrange workflow | Reorganiza visualmente tareas; no cambia sus datos de entrada |
| Fit workflow | Ajusta la vista del canvas |
| Runtime o worker de la ejecución | Condiciona compatibilidad y capacidad; no sustituye los permisos |
Los overrides de una ejecución deben tratarse como valores de ese intento. No los confunda con una edición persistente de la Session o del Workflow. Antes de reutilizar un resultado, registre cuáles se suministraron.
Programación
La sección Workflow Scheduler de Configuration administra programaciones reutilizables. Cree la programación allí y asígnela desde el Workflow. Revise calendario, zona horaria y estado antes de habilitarla. Una programación habilitada expresa intención de ejecución futura; no demuestra que una tarea haya arrancado o terminado.
Pruebe primero el Workflow manualmente. Después configure una frecuencia de laboratorio y compruebe su próxima ejecución en las vistas disponibles. Use una zona horaria explícita: la zona de su Profile para presentar fechas no debe confundirse con la zona de una programación.
POC: normalización con ramas complementarias
La muestra samples/transform_workflows/ contiene definiciones coherentes de Mapping, Session y Workflow. Cada ejemplo incluye una Session, ramas de decisión complementarias, un temporizador y un destino CSV. Para normalización de clientes, la entrada documentada contiene 1.000 filas y la salida esperada 667.
Regeneración local documentada:
python samples/transform_workflows/generate_samples.py
Use los artefactos generados como material de laboratorio. Revise primero el Mapping y los bindings de la Session; después inspeccione el Workflow y explique qué rama corresponde a cada resultado. Ejecute con datos sintéticos y conserve el identificador del intento.
El resultado esperado combina dos evidencias: una ruta de tareas consistente con las condiciones configuradas y un archivo que coincide con el oráculo independiente. No basta con que la última tarea muestre éxito si las filas o valores no corresponden. El generador y la ejecución del Workflow deben verificarse en el entorno de laboratorio; no fueron ejecutados durante esta redacción.
Validación y recuperación
Ante tareas sin iniciar, examine dependencias, estado del worker, capacidad y exclusiones. Ante una tarea fallida, abra Monitor y revise el primer error relevante, no únicamente el estado global.
Si una Session o Mapping cambió de versión, examine los avisos y los vínculos publicados antes de republicar el Workflow. Conserve la versión anterior cuando necesite comparar resultados; no use la edición de un borrador como prueba de que una programación ya consume esos cambios.
La recuperación desde checkpoint depende de lo que haya persistido el motor. No significa necesariamente volver a ejecutar todo, ni garantiza que un destino externo revierta operaciones previas. Antes de reintentar una carga, compruebe si el destino tolera duplicados o si la prueba utiliza archivos de salida independientes.
Relaciones y límites
Consulte Sessions para bindings y recuperación, Workers para capacidad y Monitor para evidencia. Este capítulo no inventaría condiciones de decisión ni expresiones no verificadas: la configuración exacta de cada componente debe revisarse en su panel y documentación específica.