Cuando escribes una consulta sobre una vista de Denodo desde una herramienta de BI, en realidad estás hablando SQL con la capa de virtualización. Pero no todos los consumidores hablan SQL: hay aplicaciones móviles que esperan JSON por REST, integraciones corporativas que quieren OData porque así lo exige su ERP, y equipos de frontend que solo se sienten cómodos con GraphQL. Denodo puede servir la misma vista por los cuatro caminos a la vez, sin duplicar una sola fila de datos.
Una vista, varias puertas de entrada
La idea de fondo es siempre la misma: la vista sigue viviendo en Virtual DataPort, con su misma lógica de combinación, sus mismos privilegios y su misma caché si la tiene configurada. Lo único que cambia es el protocolo con el que un cliente externo la pide. Denodo separa esto en dos familias de mecanismos: los servicios web publicados (REST y SOAP, creados a medida desde Design Studio) y los servicios genéricos del propio motor (OData y GraphQL, que exponen el catálogo de VDP de forma más automática).
Se crea desde Design Studio con New > Data service > REST Web service, arrastrando una o varias vistas al lienzo de «Resources». Cada vista se convierte en un recurso direccionable por URL, y puedes decidir qué campos de entrada se aceptan como filtro y cuáles se descartan.
Mismo asistente, pestaña «Operations»: cada vista o procedimiento arrastrado se convierte en una operación con nombre generado automáticamente (por ejemplo getPEDIDOByID), pensado para integraciones más clásicas basadas en WSDL.
El servicio OData 4.0 de Virtual DataPort expone el modelo de datos siguiendo el estándar OASIS: colecciones de entidades navegables, filtrado, paginación y recorrido de asociaciones, sin tener que construir un recurso por vista a mano.
Documentado dentro de la arquitectura RESTful de VDP, genera un esquema GraphQL a partir de los metadatos: cada vista se convierte en un tipo y cada asociación en una relación navegable, con soporte de introspección para que el cliente descubra el esquema por sí mismo.
Publicar un servicio REST paso a paso
Sobre una carpeta del servidor, el asistente + New > Data service > REST Web service abre tres pestañas: Resources (qué vistas se publican y qué parámetros de entrada acepta cada una), Settings (formato de salida y autenticación) y Advanced (opciones de representación y conexión). El formato de salida puede ser HTML, XML o JSON —HTML es el que viene por defecto, así que conviene cambiarlo explícitamente si el consumidor real va a ser una aplicación—. Una vez configurado, el servicio se despliega desde Tools > Web services container, y ahí mismo Denodo te muestra la URI completa del contexto, algo con esta forma:
http://host:9090/server/almacen/pedidos_service/views/pedidos?cliente_id=C0045
Sobre la autenticación: por defecto un servicio publicado no pide credenciales, lo cual casi nunca es lo que quieres en producción. La opción «HTTP Basic with VDP» delega la autenticación en el propio servidor de Denodo, de modo que solo puede invocar el servicio quien ya tendría permiso para consultar la vista por VQL. También hay Digest, OAuth 2.0 y variantes WSS para SOAP, según lo que exija el consumidor.
Cuándo usar cada mecanismo
| Mecanismo | Encaja bien cuando… |
|---|---|
| REST | Necesitas un endpoint concreto, con nombre de negocio, para una app o integración puntual. |
| SOAP | El consumidor es un sistema legado que ya trabaja con WSDL y operaciones tipadas. |
| OData | Quieres exponer varias vistas relacionadas de una tirada, con filtrado y paginación estándar, típico de herramientas que «hablan» OData de fábrica. |
| GraphQL | El consumidor prefiere pedir exactamente los campos que necesita, incluyendo los de vistas asociadas, en una sola llamada. |
Cosas que conviene revisar antes de publicar nada
- Define bien la clave primaria de la vista: los servicios de datos la necesitan para identificar recursos de forma unívoca, sobre todo en REST y en las asociaciones que navega OData.
- Decide el formato de salida explícitamente en Settings; dejarlo en HTML por defecto es una fuente clásica de sorpresas cuando el consumidor esperaba JSON.
- No publiques un servicio sin autenticación delegada salvo que sea intencionadamente público: es la puerta de entrada más visible de toda la capa de virtualización.
- Revisa qué campos de entrada dejas activos como filtro; cuantos menos innecesarios expongas, más claro queda el contrato del servicio.
- Si vas a exponer varias vistas relacionadas, valora OData o GraphQL antes que construir un REST a medida por cada una.
Ninguno de estos cuatro mecanismos sustituye a los otros: en un proyecto real es habitual convivir con un REST a medida para una integración concreta y, en paralelo, tener el servicio OData o GraphQL activo para consumo más exploratorio. Lo que no cambia es dónde vive la lógica: en la vista de Denodo, no en el protocolo que la envuelve.
¿Quieres que esa carga de caché detrás de tus servicios se ejecute sola, sin que nadie tenga que lanzarla a mano?
Ver cómo lo hace Denodo Scheduler