Los workers ejecutan Sessions y Workflows según la política del tenant. Heartbeat, estado de energía de la VM y elegibilidad son observaciones diferentes. Un worker público puede ofrecer capacidad compartida; asignarle una Session no publica su definición, sus datos ni sus artefactos para otros usuarios o tenants.
Antes de empezar
Prepara un host autorizado y conoce su propietario. Necesitas capacidad compatible, permisos y acceso de red a los recursos del proceso. Los archivos de entrada deben estar disponibles para el worker; seleccionarlo no los copia automáticamente.
Procedimiento
- Abre Workers e identifica el registro por identificador, tenant o pool y heartbeat reciente. No te bases únicamente en el nombre.
- Abre su detalle y revisa versión, recursos, conectores y slots. Compara con los requisitos de la Session y el Execution profile.
- Si debes registrar un host, usa el procedimiento de enrollment autorizado y conserva el token en el flujo protegido. Comprueba que aparezca un heartbeat válido.
- Distingue reiniciar el servicio worker de encender una VM en el proveedor. El aprovisionamiento y los controles de proveedor corresponden a Administrator.
- Selecciona el valor por defecto o una asignación explícita permitida. Comprueba que la identidad pueda resolver Connections y acceder al archivo de entrada.
- Ejecuta una Session sintética y verifica en Monitor qué worker recibió el intento y cuál fue su resultado.
- Antes de retirar o sustituir capacidad, revisa trabajos activos, referencias, políticas por defecto y dependencias.
Comprobar el resultado
El registro está actualizado, es elegible para el trabajo y completa una prueba con resultado conocido. Los slots son unidades ponderadas: cuatro slots pueden admitir cuatro trabajos de peso uno o dos de peso dos, sujetos a otros límites. Online no significa capacidad ilimitada.
Errores y recuperación
Sin heartbeat, revisa servicio y conectividad permitida. Ante inelegibilidad, inspecciona políticas, capacidades, recursos y ciclo de vida. Provider unavailable no prueba que la VM no exista. Una eliminación fallida debe resolverse mediante el procedimiento soportado; no borres registros para ocultar el problema.
Ejemplo sintético
Asigna s_CustomerNames a lab-worker, con un CSV sintético disponible allí. Comprueba el identificador del worker y la versión de Mapping utilizados en el intento.
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.
Pool de workers por entorno
En Configuration → Dova Integration Runtime, Environment worker pool muestra el entorno actual. Allowed workers permite asignar workers existentes; Default worker debe pertenecer a esa selección. Pool policy empieza en Dedicated. Selecciona Shared únicamente cuando decidas compartir capacidad y todos los pools participantes también declaren Shared. Un worker físico no se comparte por una coincidencia de nombre.
Save environment pool guarda solamente la política del entorno seleccionado y no inicia una ejecución ni cambia el default global del tenant. La revisión usa una huella de la configuración; si otro usuario la cambia, Refresh pool permite consultar y revisar nuevamente antes de guardar. Los controles requieren administración de configuración y Runtime por entorno. Built-in no se ofrece como worker de ejecución.
Production no toma prestado automáticamente el pool de Development. Los nuevos trabajos requieren un pool explícito, salvo la opción pública de Development para un Trial elegible descrita a continuación. Las ejecuciones legacy solo pueden conservar su worker anterior cuando el servidor verifica la cadena publicada exacta, su configuración y la pertenencia permitida. Test y Stage consumen el bucket Development del plan; Production usa el bucket Production. La pertenencia al pool no sustituye capacidad, estado online, perfil compatible, cuotas ni concurrencia.
Trial público: pool Development gestionado
Para un Trial público elegible, si no existe una política explícita de Development, Dova obtiene un pool público de Development gestionado por la plataforma. Selecciona únicamente workers públicos compartidos con referencias verificadas, autorizados para el Trial y sin pertenencia a otros pools configurados. No incorpora workers privados, crea workers ni guarda cambios en Runtime. El Trial no obtiene permiso para guardar pools.
Una política explícita de Development, incluso con Allowed workers vacío, tiene prioridad. Este mecanismo no se extiende a Test, Stage o Production. Siguen vigentes las comprobaciones de capacidad, perfil, aislamiento, cuotas y concurrencia; el acceso público no garantiza disponibilidad.
Antes de detener o retirar capacidad
Pause VM y Stop VM conservan sus comprobaciones de trabajos activos, worker predeterminado y capacidad compartida; revisa las referencias y el impacto antes de utilizarlos. Pause scheduling detiene nuevas asignaciones y permite terminar el trabajo actual. Para retirar definitivamente la VM, utiliza Remove VM and unlink y revisa su confirmación: después de verificar ausencia cloud, Dova limpia las asignaciones y muestra Unassigned sin borrar definiciones ni versiones publicadas. Antes de ejecutar de nuevo, asigna capacidad compatible explícitamente.
Las acciones requieren el permiso del módulo y Runtime del entorno correspondiente, o un permiso global concedido explícitamente. Una VM compartida requiere autorización sobre todos sus entornos.
Retirada y asignación posterior
Abre Remove VM and unlink, revisa la identidad del recurso y el impacto en las Sessions, ejecuciones y pools, y confirma la eliminación prevista. Para una VM propia compatible, no necesitas desarmar manualmente cada referencia ni apagarla como requisito previo de esta operación. Retirar capacidad puede interrumpir ejecuciones activas; programa la operación según tu necesidad.
Después de confirmar la ausencia en el proveedor, Dova retira el worker activo, limpia referencias de Runtime y muestra Unassigned en los bindings de Sessions que usaban ese worker. Conserva las definiciones, versiones publicadas, configuración e historial de auditoría. Si la VM se elimina directamente en el proveedor, la conciliación aplica el mismo tratamiento cuando comprueba su ausencia. Un error al consultar al proveedor no demuestra que la VM se haya borrado.
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.