Cuando configuras la caché de una vista de Denodo, tarde o temprano llega la pregunta incómoda: ¿quién la recarga cada noche? La respuesta casi siempre es Denodo Scheduler, el componente de la plataforma pensado para automatizar justo ese tipo de tareas recurrentes de mantenimiento, sin depender de un cron externo ni de que alguien se acuerde de lanzar un script.
Qué es y qué problema resuelve
Scheduler es, en esencia, un motor de tareas planificadas que sabe hablar con Virtual DataPort de forma nativa. Según la propia documentación de Denodo, sirve tanto para automatizar tareas administrativas típicas —precarga de caché, generación de estadísticas, limpieza de la base de datos de caché, refresco de datos resumen— como para actuar como una herramienta de ETL ligera: extraer el resultado de una consulta VQL, transformarlo mínimamente si hace falta y exportarlo a un destino (una tabla JDBC, un fichero CSV, etc.).
La diferencia con lanzar esas mismas consultas «a mano» es que Scheduler añade todo lo que rodea a una tarea productiva: planificación por cron, reintentos si algo falla, notificaciones y un histórico de ejecuciones consultable desde su propia herramienta de administración.
Cómo se construye un job
Antes de crear ninguna tarea hay que dar de alta, en la herramienta de administración de Scheduler, las conexiones que va a usar: el origen de tipo VDP (el servidor de Denodo del que extrae datos) y, si aplica, la base de datos destino donde exportará resultados. A partir de ahí, un job de tipo VDP se configura en varias pestañas:
Se elige el origen VDP configurado y se escribe la consulta a ejecutar. Puede llevar valores fijos o parámetros dinámicos con prefijo @, lo que permite reutilizar el mismo job con distintos filtros según cómo se lance.
Se selecciona el exportador (JDBC, CSV, entre otros) y el destino: tabla, esquema y catálogo si es una base de datos, o ruta de fichero si es un export plano.
Se define qué pasa si la ejecución falla, o si el número de registros exportados no llega a un umbral esperado, y se pueden añadir notificaciones (por ejemplo por correo) asociadas a esos eventos.
La planificación en sí se define con una expresión cron. El job también puede lanzarse en cualquier momento a mano, desde la herramienta de administración o por API, sin esperar a su disparador.
El caso más habitual: mantener la caché al día
Aunque Scheduler sirve para bastante más que caché, en la mayoría de proyectos su uso más frecuente es justamente ese: mantener actualizadas las vistas que tienen caché activada en Virtual DataPort. La guía de administración de Scheduler dedica secciones específicas a la configuración de este tipo de tareas, distinguiendo entre una gestión de caché «simple» sobre una lista de vistas y una gestión pensada para respetar las dependencias entre vistas relacionadas, de forma que una vista no se recargue antes de que lo haya hecho aquello de lo que depende.
Por qué importa el orden: si dos vistas cacheadas están relacionadas y se recargan en el orden equivocado, durante un rato conviven datos de instantes distintos detrás de la misma consulta. Por eso, cuando hay dependencias reales entre vistas, conviene apoyarse en la opción de Scheduler pensada para respetarlas en lugar de lanzar cargas independientes «a ojo».
Detalles que se pasan por alto la primera vez
- Un job puede ejecutarse tanto por su cron como manualmente o vía API; no hace falta esperar al disparador para probarlo.
- Los parámetros con prefijo
@permiten reutilizar un mismo job para distintos filtros en lugar de duplicarlo por cada variante. - Configura umbrales de filas exportadas y notificaciones de fallo: sin ellos, una carga de caché que falla en silencio puede pasar días sin que nadie lo note.
- Si varias vistas cacheadas dependen unas de otras, planifica su recarga respetando esa dependencia en lugar de tratarlas como jobs sueltos.
- Antes de programar una tarea nueva en producción, ejecútala una vez a mano y revisa el histórico de la herramienta de administración.
Scheduler no sustituye a un orquestador corporativo si ya tienes uno, pero para lo que ocurre dentro del propio ecosistema Denodo —refrescar caché, regenerar estadísticas, mover pequeños volúmenes entre una vista y un destino— es la pieza pensada específicamente para eso, y suele ahorrar bastantes scripts caseros.
¿Ya tienes las cargas automatizadas? El siguiente paso lógico es exponer esas vistas hacia fuera como servicio.
Ver cómo publicar vistas como REST, OData y GraphQL