Publicación y versiones de las dependencias

Prepare y publique la cadena Mapping → Session → Workflow sin confundir borradores, versiones y resultados de ejecución.

Tres objetos, tres responsabilidades

Un Mapping describe el flujo de datos. Una Session referencia una versión de Mapping y define bindings, parámetros y perfil de ejecución. Un Workflow selecciona Sessions y organiza sus tareas. El conjunto que se publica debe ser coherente: un Workflow publicado no corrige automáticamente una Session incompleta ni autoriza acceso a una Connection.

Trabaje en una ubicación de laboratorio y compruebe permisos de edición, publicación y ejecución por separado. Prepare archivos sintéticos, Connections autorizadas y capacidad de worker antes de aceptar la cadena.

Guardar, publicar y ejecutar

Acción	Qué debe comprobar
`Save draft`	Los cambios editables quedan guardados. Todavía no existe evidencia de una nueva ejecución.
`Validate`	La definición cumple las comprobaciones del objeto. No prueba conectividad ni datos finales.
`Publish`	La versión queda disponible para consumidores autorizados. Revise las dependencias seleccionadas.
`Run`	Se crea un intento con contexto de ejecución. Consulte después su estado y su resultado real.

Guardar un archivo CSV en el navegador no lo coloca en el sistema de archivos de un worker. Del mismo modo, crear un borrador con DovaAI no publica ni ejecuta el diseño.

Publicar una cadena controlada

Abra el Mapping, compruebe origen, transformaciones, destino y esquema. Valide y guarde el borrador.
Publique el Mapping y anote la versión elegida para el laboratorio.
Abra la Session y revise su referencia de Mapping, versión y bindings de entrada/salida. Valide y publique la Session.
Abra el Workflow. En cada tarea Session, compruebe Reusable session y la versión consumida. Revise los avisos de dependencia.
Valide conexiones y condiciones, guarde el borrador y publique el Workflow.
Ejecute manualmente con una salida de laboratorio independiente. Registre el intento y contraste Monitor con el archivo o destino obtenido.

Ejemplo: cambiar una regla sin perder trazabilidad

Suponga que m_CustomersActive v1 conserva status=ACTIVE. Su Session v1 y Workflow v1 fueron aceptados con tres filas. Ahora modifica el Mapping para descartar también amount=0. El resultado esperado de esa nueva regla será de dos filas en la muestra del laboratorio.

Publique deliberadamente la versión nueva del Mapping, revise qué referencia conserva la Session y actualice sus consumidores mediante las acciones disponibles. Haga lo mismo con el Workflow y vuelva a probar. Conserve ambos resultados para explicar la diferencia. No deduzca la versión ejecutada a partir del borrador que quedó abierto en otra pestaña.

Evidencia mínima de aceptación

Nombre y versión de cada objeto de la cadena, junto al identificador del intento.
Parámetros y bindings efectivos de la prueba, sin copiar secretos.
Estado de las tareas y primer error relevante, si existe.
Esquema, cantidad de registros y reglas de negocio verificadas en la salida.

Las referencias de Mapping pueden incluir versión y fingerprint; una ejecución fija su contexto autorizado. Esto permite identificar qué se consumió, pero no convierte un archivo externo mutable en una entrada inmutable. Preserve o identifique también los datos de prueba.

Actualizar o volver a una referencia conocida

Si aparece una dependencia no disponible, compruebe publicación, tenant, ubicación, permisos y versión. Si el diseño guarda bien pero Run falla, investigue worker, rutas, Connections y datos. No republique repetidamente como sustituto de leer el error.

Para comparar con una versión aceptada, utilice los mecanismos de versiones y referencias disponibles y una salida separada. Restaurar una definición no revierte escrituras previas en bases de datos, API o almacenamiento. Antes de habilitar una programación, complete la revisión de calendario.