Antes de comenzar
Una Session reutiliza un Mapping publicado en un contexto de ejecución. No redefine su algoritmo. Prepara una versión aceptada, una ubicación autorizada y capacidad compatible. Mantén separadas las autorizaciones para editar, publicar y ejecutar. Los archivos locales del navegador no aparecen automáticamente en el sistema de archivos del worker.
Elige un entorno y un destino de laboratorio antes de probar escrituras. Registrar Production como entorno no concede permiso ni publica el artefacto.
Procedimiento
- Crea la Session y selecciona el Mapping publicado. Comprueba su identificador y versión, no solo el nombre.
- Revisa el entorno y la política de worker. Conserva el valor heredado si no necesitas una asignación explícita; cualquier selección debe cumplir capacidades y permisos.
- Completa conexiones y bindings de entrada/salida. Usa rutas accesibles por el worker elegido y una salida exclusiva para la prueba.
- Configura parámetros declarados con tipos correctos. Los overrides de tarea pertenecen al Workflow, no a las capas de la Session.
- Revisa timeout, reintentos y recuperación. Guarda el borrador y publica la versión aceptada antes de consumirla desde un Workflow.
Ejemplo sintético
Un Mapping lee name,amount de un CSV y conserva ambas columnas. Crea dos Sessions con la misma referencia de Mapping: una para Test y otra para Stage. Usa entradas equivalentes y salidas diferentes. Las diferencias de rutas pertenecen a los bindings; no necesitas duplicar el algoritmo para cambiar únicamente el archivo.
Comprobar el resultado
Reabre la Session y confirma referencia de Mapping, versión, entorno, política de worker y bindings. Si usas parámetros, revisa el origen del valor resuelto. Crea un Workflow de laboratorio para cada contexto y compara esquema y datos producidos. Un guardado correcto no demuestra que las conexiones o archivos sean accesibles durante la ejecución.
Al actualizar un Mapping, revisa el aviso de dependencia y acepta la nueva versión de forma deliberada. Comprueba después los Workflows que consumen esa Session.
Resolver problemas
Para un archivo ausente, corrige su binding y revisa permisos del worker. Para falta de capacidad, distingue estado del worker, slots, requisitos y políticas del tenant. Un error JSON debe corregirse sin descartar otros ajustes del borrador. Un checkpoint solo ayuda si existe estado utilizable; no revierte automáticamente escrituras externas. Antes de repetir una carga, determina si el destino admite reintentos sin duplicados.
Runtime: perfil, nombres y variables
En Runtime elige Execution profile y revisa sus límites de entrada, memoria, disco y timeout junto con la capacidad del worker. Un perfil automático puede admitir menos bytes que tu archivo; el espacio libre de la VM no aumenta ese límite ni la memoria temporal del ejecutor aislado.
Available runtime variables muestra nombre, significado, Example preview y Last resolved value. El ejemplo ayuda a preparar la configuración; el valor resuelto pertenece al run identificado y su fecha. Los valores sensibles se ocultan. Si aún no hay un intento compatible, la ausencia de valor real no se sustituye por el ejemplo.
Para nombres de salida usa Target filename timestamp y Target filename template. %RUN_TIMESTAMP% se resuelve al iniciar el intento. Enabled lo activa para esa Session; Disabled lo desactiva; Inherit sigue la preferencia global. Escribir el token en el template mientras Inherit resulta desactivado no activa el reemplazo. Filename preview · example ilustra el nombre, no prueba la salida real de un run. Guarda y publica para que los consumidores puedan adoptar el cambio.
General: elegir ubicación antes del Mapping
Después de Name, completa Domain → Folder → Mapping y luego Environment y Status. Los mappings disponibles se filtran por Domain y permisos de uso compartido, y se cargan desde la apertura del formulario sin volver a seleccionar Domain. Folder organiza la Session y no obliga al Mapping a estar en la misma carpeta. Al cambiar la ubicación, revisa las opciones y conserva una referencia válida antes de guardar.
TRACE opcional
En Sessions → Runtime, TRACE permite elegir Inherit from Workflow, Enabled o Disabled. Inherit from Workflow toma el ajuste del Workflow que la ejecuta; una ejecución directa de Session sin Workflow lo resuelve como desactivado. Enabled y Disabled sustituyen la herencia para esa Session. Por defecto se usa Inherit from Workflow y los Workflows nuevos tienen TRACE desactivado.
El ajuste controla la generación de detalle TRACE para los intentos nuevos; no elimina evidencia histórica ni oculta INFO, WARNING o ERROR. Guarda, publica y actualiza las versiones del Workflow cuando corresponda para ejecutar el ajuste aceptado.
Contexto de entorno
Antes de utilizar este módulo confirma Tenant, Domain y Environment en el menú de usuario. El entorno inicial es Development. Las capacidades del módulo, el Domain y el entorno se aplican juntas; Production queda de solo lectura sin autorización explícita. Cambiar el selector no mueve artefactos ni publica o ejecuta sus datos. Consulta entornos y recuperación y promoción entre entornos.
Worker Unassigned
Antes de volver a ejecutar, selecciona un worker compatible y permitido y revisa el pool del entorno. Unassigned no toma otro worker automáticamente. Puedes aprovisionar una VM nueva y asignarla explícitamente. Los permisos, la propiedad del recurso, el servidor base protegido y las operaciones pendientes siguen verificándose; la retirada no es una forma de eludir esas protecciones.
Barra de la lista y alcance del entorno
En la lista de Sessions, los botones de acciones usan íconos con ayuda y nombres accesibles y se alinean con Search y los filtros. Puedes identificarlos con el puntero o recorriéndolos con Tab. El filtro Environment se elimina de esta lista: se usa el contexto Tenant, Domain y Environment seleccionado en el menú de usuario y visible en la barra inferior. Runtime y los demás filtros permanecen disponibles. Este cambio de la lista no elimina la configuración Runtime de la Session ni sus requisitos de worker.