Monitor: seguimiento y diagnóstico de ejecuciones

Objetivo y modelo

Monitor permite seguir intentos de ejecución y consultar su resultado. Su unidad principal es la ejecución, no la definición del Workflow. Dos ejecuciones del mismo Workflow pueden utilizar entradas, parámetros y momentos distintos; deben compararse mediante sus identificadores y el contexto registrado.

Un estado de éxito representa el resultado informado por el motor. La aceptación funcional exige comprobar también la salida: conteo de filas, esquema, valores esperados y ubicación del archivo o tabla. Un error de entrega de notificación tampoco debe confundirse automáticamente con un error de transformación.

Requisitos y lectura de la vista

Necesita permisos para consultar ejecuciones del tenant activo. Acciones como ejecutar, cancelar, recuperar o limpiar historial sólo deben utilizarse cuando estén disponibles para su rol. El alcance de un usuario lector no debe ampliarse para solucionar un problema de visualización.

Revise la vista de ejecuciones y los controles de búsqueda, estado, columnas y período disponibles. En pantallas pequeñas, una tabla ancha puede necesitar desplazamiento horizontal dentro de su contenedor. Ese desplazamiento permite llegar a acciones y filtros sin alterar el ancho de toda la página.

Las pestañas List, Gantt y Notifications separan la lista operativa, la lectura temporal y el historial de entregas. List y Gantt comparten los filtros superiores. History permite expresar una ventana en minutes, hours o days; compruebe esa unidad antes de interpretar una ausencia de registros. Notifications tiene su propia tabla y paginación de entregas: una fila allí no representa una ejecución adicional del Workflow.

Procedimiento de investigación

1. Localice la ejecución por Workflow, estado y momento.
2. Abra su detalle o Operational log cuando la acción esté disponible.
3. Busque la primera tarea fallida y relacione el mensaje con su Mapping, Session y worker.
4. Revise entradas y parámetros del intento; no deduzca esos valores únicamente del borrador que está abierto actualmente.
5. Compruebe el destino antes de decidir una recuperación.
6. Registre identificador, hora y mensaje resumido, excluyendo secretos y datos sensibles.

POC: fallo controlado y recuperación

Use el Workflow sintético de Workflows con un origen pequeño. Realice un primer intento con una ruta de laboratorio inexistente, configurada en la Session de prueba. Resultado esperado: el intento termina con un error identificable y no produce una salida válida.

Restaure la ruta correcta y realice un nuevo intento conforme a las acciones autorizadas. Compare ambos identificadores. El segundo resultado esperado es una ejecución terminada correctamente y una salida que cumple el conteo previsto. Mantenga archivos de salida separados para distinguir una nueva ejecución de un archivo residual.

Si ensaya recuperación por checkpoint, confirme primero que el intento tiene un checkpoint utilizable y que el destino soporta el comportamiento de reanudación. Un proceso externo parcialmente escrito no se revierte sólo porque el usuario pulse recuperar.

Errores y mantenimiento

Una ejecución pendiente puede esperar un worker elegible, capacidad libre o la satisfacción de dependencias. Consulte Configuration y Workers antes de repetir la solicitud. Un worker offline, una VM detenida y un proveedor unavailable son situaciones distintas.

La limpieza de historial terminado es una operación de mantenimiento con permisos y confirmación propios. Consulte el resumen y sus bloqueos; no utilice la limpieza para ocultar una incidencia aún no investigada. Conserve la evidencia necesaria fuera de capturas con datos personales.

Relaciones y límites

Overview ofrece un resumen; Monitor aporta contexto por intento. Las correcciones persistentes se realizan en Mappings, Sessions o Workflows y deben seguir su ciclo de publicación. Esta POC describe un ensayo de aceptación, no evidencia de un ensayo ya ejecutado por el manual.