Configuration: runtime, perfiles, scheduler y salud

Objetivo y estructura

Configuration concentra cuatro pestañas: Dova Integration Runtime, Execution profiles, Workflow Scheduler y Runtime health. Agrupa controles relacionados, pero cada uno tiene un propósito distinto. El runtime describe identidad y capacidad; el perfil establece condiciones de ejecución; el scheduler organiza cuándo solicitar trabajos; la salud ayuda a diagnosticar el entorno.

La vista conserva controles y contenido desplazable. En escritorio, las pestañas permanecen separadas del área de contenido; en tablas anchas puede existir desplazamiento horizontal interno. Use teclado o toque para alcanzar acciones sin interpretar una columna fuera de pantalla como una función inexistente.

Requisitos y decisiones

Los permisos condicionan consulta y administración. No todos los usuarios pueden registrar workers, guardar políticas, crear perfiles o modificar programaciones. Antes de cambiar una política de tenant, revise las Sessions que heredan ese valor.

Dova Integration Runtime

Revise identidad, estado, modo, worker predeterminado y capacidades. Runtime inventory incorpora búsqueda, actualización y selección de columnas. El resumen de workers distingue disponibilidad, slots, cola y exclusiones.

En Tenant routing policy, examine Default worker, Fallback y Save policy. El código vigente envía una política estricta; no presuponga un fallback automático a cualquier worker. Las exclusiones y la compatibilidad se aplican antes de decidir el destino de ejecución.

Las subpestañas Workers y Exclusion rules permiten revisar inventario y restricciones. Una exclusión representa una decisión de routing, no una eliminación del worker.

Perfiles y programación

En Execution profiles, busque el perfil existente antes de crear otro. Revise sus consumidores y límites; un perfil de ejecución no es una plantilla de aprovisionamiento cloud de Administrator.

En Workflow Scheduler, cree una programación reutilizable y valide su nombre, frecuencia, zona horaria y estado. Asígnela después desde el Workflow que deba utilizarla. Pruebe manualmente el Workflow antes de habilitar una frecuencia repetitiva. La próxima fecha programada no es un resultado de ejecución.

POC: política heredada y override

Prepare dos Sessions de laboratorio que utilicen el mismo Mapping publicado. En la primera, conserve Use tenant default; en la segunda, active Override worker sólo si existe otro worker elegible.

Anote la política actual y compruebe las dos Sessions sin cambiar inicialmente ningún valor global. Resultado esperado: la primera resuelve mediante la política del tenant y la segunda conserva la selección explícita, siempre sometida a elegibilidad.

En un tenant exclusivamente de laboratorio, cambie el worker predeterminado mediante Save policy y vuelva a revisar las Sessions. Compruebe qué valor efectivo muestra cada una y ejecute una entrada mínima si dispone de autorización. Restaure la política anterior al terminar. No haga este ensayo sobre un tenant con cargas compartidas activas.

Errores y recuperación

Si no hay workers elegibles, revise capacidades, estado, exclusiones y perfil. Si una programación no genera el resultado esperado, contraste zona horaria y estado con Monitor. No cambie simultáneamente política, perfil y horario: perdería la capacidad de identificar la causa.

Ante un error al guardar, conserve el mensaje, recargue cuando resulte seguro y confirme el valor persistido antes de repetir. Una selección visible en un formulario no prueba que la política del servidor haya cambiado.

Relaciones y límites

Consulte Workers, Sessions y Workflows. La POC documenta una comprobación controlada, no una ejecución realizada al redactar el manual ni una promesa de capacidad o disponibilidad.