Información general
¿Cuándo utilizarla?
Cuando estés desarrollando una aplicación con interfaz web/app en la que interese integrar datos dentro de la plataforma tecnológica asociada al Portal Junta o consumir información que está disponible en ella.
El objetivo de esta plataforma es facilitar el intercambio y publicación, a través de cualquier web, de la información proveniente de distintos sistemas de información, así como ofrecer un mecanismo sencillo para la apertura de datos y reutilización de la información pública, utilizando los servicios que se ofrecen en la plataforma para facilitar esta tarea a los desarrolladores.
Finalidad y casos de uso
Ejemplos de casos de uso:
- Publicación de datos en portales web: Exposición de información estructurada en el Portal de la Junta, en webs orgánicas de consejerías y agencias, o en cualquier otra web.
- Consumo de datos vía API: Acceso a los datos disponibles en la plataforma para su reutilización a través de una interfaz compatible OpenAPI.
- Apertura de datos públicos: Publicación en el Portal de Datos Abiertos de conjuntos de datos accesibles a la ciudadanía, cumpliendo estándares de calidad y transparencia.
Características y ventajas
Se trata de una plataforma abierta y flexible, basada en estándares y normas explícitas, que proporciona una alta disponibilidad y escalabilidad. Permite el aprovisionamiento ágil de los entornos y el despliegue automatizado de los servicios, al estar basada en tecnologías cloud-native y orientarse a la metodología DevSecOps.
Su uso permite la interoperabilidad técnica y semántica, facilitando la integración de los datos y el acceso a los mismos de una manera sencilla, así como pretende facilitar el gobierno del dato público y la analítica omnicanal de la presencia digital institucional.
Se promueve expresamente la reutilización de recursos (tales como: arquetipos, componentes web, hojas de estilo…) con el objetivo de facilitar y acelerar el desarrollo de nuevos servicios digitales, estandarizando a su vez la presencia digital en Internet, alineando las webs y apps con el sistema de diseño de la Junta de Andalucía.
Detalle técnico
La solución se basa en un flujo de interacción entre el usuario, el portal y los sistemas de backend:
- El usuario accede al Portal Junta de Andalucía
- Solicita información desde una página, buscador o mediante descarga.
- El portal envía la solicitud al backend a través del API Manager.
- El backend procesa la petición.
- Opcional La información puede estar en recursos accesibles por el backend.
- Opcional Si los datos están en sistemas externos, se envía la petición al bus de interoperabilidad
- Opcional El bus solicita la información al sistema experto
Cómo adaptarla a tu caso concreto
Adaptación
Para aplicar esta solución en tu proyecto, es necesario identificar qué papel desempeña cada actor y qué modelo de integración se ajusta mejor al origen de los datos, a la forma en que se actualizan y a la capacidad del sistema proveedor para ponerlos a disposición de la Plataforma Tecnológica.
Modelos de integración
La Plataforma Tecnológica contempla tres modelos principales de integración: extremo a extremo, interoperable y con recursos estáticos
- Extremo a extremo: Los datos se gestionan directamente en la plataforma, por ejemplo, mediante el Gestor de Contenidos del portal www.juntadeandalucia.es (CMS basado en solución Drupal).
- Interoperable: Los datos provienen de sistemas externos y se comunican mediante API REST.
- Recursos estáticos: Es la alternativa más simple cuando el sistema proveedor no puede ofrecer servicios para consulta directa de la información. Los datos se proporcionan en forma de exportación completa.
A continuación, describimos cada uno de estos modelos, y si precisas más información, consulta la presentación del modelo de integración que encontrarás en la sección de documentación en esta página.
Actores
Proveedor: sistema de información que genera, custodia o pone a disposición los conjuntos de datos que se desean integrar en la Plataforma Tecnológica. Según el modelo de integración, puede hacerlo mediante servicios de consulta o mediante la entrega de ficheros exportados.
Adaptador: componente encargado de conectar la información del proveedor con la Plataforma Tecnológica y facilitar su incorporación al proceso de integración.
Consumidor: producto digital, como una web, portal o aplicación, que accede y utiliza la información integrada a través de los servicios de la plataforma.
Equipo de desarrollo: responsable de implantar la solución de integración, preparar la información necesaria y realizar las pruebas correspondientes, tanto en integraciones basadas en servicios como en integraciones mediante ficheros.
Oficina del Modelo de Servicios Digitales: responsable de acompañar al equipo integrador, validar el enfoque cuando sea necesario y gestionar el alta y la configuración del proveedor en la Plataforma Tecnológica
Para más información, consulta la presentación del modelo de integración (disponible en la sección de documentación).
Modelo de integración extremo a extremo
Este modelo está orientado a sistemas proveedores que pueden integrarse de forma directa con la Plataforma Tecnológica, aprovechando sus servicios comunes y su modelo habitual de funcionamiento. En estos casos, la gestión y publicación de los datos se realiza de forma alineada con el ecosistema de la propia plataforma, lo que simplifica la integración y favorece su reutilización posterior. Por ejemplo, este sería el caso de un tipo de contenidos específico creado en un Sistema de Gestión de Contenidos desplegado en la plataforma.
Entre las ventajas de este modelo, posibilita la integración con otros servicios disponibles en la plataforma, la interoperabilidad de los datos a través de API Manager, el uso de las herramientas horizontales y el soporte del equipo responsable de la plataforma a través de un modelo de trabajo DevSecOps.
Modelo de integración interoperable
En este modelo, los datos proceden de un sistema proveedor externo a la Plataforma Tecnológica. La integración se realiza de forma que la plataforma pueda incorporar, mantener actualizada y poner a disposición esa información para su reutilización por otros productos digitales.
Está pensado para sistemas que no están implantados en la plataforma, pero que sí pueden integrarse con ella. En función de las características del sistema origen, puede requerirse un análisis previo o la definición de un componente de adaptación específico. Este mecanismo de indexación e integración de datos optimizados para su lectura se corresponde con el patrón arquitectónico Vista Materializada.
Integración del sistema usando la API
En los modelos de integración extremo a extremo e interoperable, la relación del sistema proveedor con la Plataforma Tecnológica sigue el mismo patrón general: el proveedor comunica los cambios que se producen en sus datos y la plataforma recupera la información necesaria para integrarla y publicarla.
Para ello, el sistema proveedor debe exponer una API que permita cubrir dos necesidades:
- Notificar eventos de cambio sobre los datos de origen.
- Facilitar la consulta del contenido cuando la plataforma necesite recuperarlo.
| Finalidad | Operación | Patrón |
|---|---|---|
| Notificación de creación | POST | /events/hydra/{dataset}/{id} |
| Notificación de actualización | PUT | /events/hydra/{dataset}/{id} |
| Notificación de borrado | DELETE | /events/hydra/{dataset}/{id} |
| Obtención de un contenido concreto | GET | /{dataset}/{id} |
| Obtención del número total de registros | GET | /{dataset}/count |
Estas operaciones permiten a la plataforma reaccionar ante las altas, modificaciones y bajas de los datos, así como recuperar el contenido completo de un elemento cuando sea necesario.
Se recomienda que la API expuesta sigua las indicaciones del estándar OpenAPI.
Cómo se utilizan estas operaciones
Cuando el sistema proveedor crea o actualiza un contenido, debe enviar una notificación a la plataforma. A partir de esa señal, la plataforma recupera después el contenido completo mediante la operación de consulta por identificador y lo incorpora al proceso de integración e indexación.
Cuando el sistema proveedor elimina un contenido, debe comunicar esa baja mediante la operación de borrado. En este caso, la plataforma no necesita volver a consultar el contenido completo, sino únicamente identificar el elemento que debe retirarse
Operaciones Recomendadas
| Finalidad | Operación | Patrón |
|---|---|---|
| Obtención paginada de registros | GET | /{dataset}?offset={n}&limit={m} |
| Obtención de todos los registros | GET | /{dataset}/all |
Estas operaciones permiten recuperar los datos o bien de forma completa o de progresiva por bloques, lo que resulta especialmente útil en procesos de sincronización masiva
Integración con recursos estáticos
Este modelo de integración está pensado para aquellos casos en los que el sistema proveedor no dispone de una API propia o en los que resulta más conveniente publicar la información mediante ficheros estáticos. Es una opción especialmente adecuada para cargas periódicas, para sistemas heredados o para servicios en los que la información no se actualiza con mucha frecuencia.
En este modelo, los datos se entregan en forma de fichero y se depositan en un espacio de almacenamiento de objetos gestionado compatible con AWS S3 (Minio). A partir de esa entrega, la Plataforma Tecnológica detecta la nueva información, la procesa automáticamente y la incorpora al circuito de indexación y publicación.
Cómo funciona
El funcionamiento general de esta integración es el siguiente:
- El sistema proveedor, o el equipo responsable, sube un fichero al bucket de MinIO asociado a la integración.
- La llegada del fichero dispara un evento en el almacenamiento de objetos, que notifica a la Plataforma Tecnológica que hay nueva información disponible.
- La plataforma descarga y procesa el fichero aplicando las reglas definidas para ese conjunto de datos.
- Finalmente, los datos se indexan y quedan disponibles para su reutilización a través de los servicios de entrega de la plataforma.
Qué hay que preparar
Para poner en marcha este modelo, es necesario definir:
- el conjunto de datos que se va a publicar;
- la frecuencia de actualización prevista;
- el procedimiento de entrega de los ficheros, que puede ser manual o automatizado;
- y la configuración del proveedor en la plataforma, incluyendo el espacio de almacenamiento, el patrón de nombre del fichero, la definición de transformación, el campo identificador y el índice de destino.
Carga completa de contenidos
En este modelo la carga es completa. Es decir, cada fichero entregado representa una versión completa de la información que debe quedar publicada en la plataforma.
Este enfoque simplifica la preparación de la información, facilita la validación del resultado y resulta especialmente apropiado cuando el contenido tiene una actualización moderada o poco frecuente. Por ello, suele ser la opción más recomendable en servicios donde no se necesita sincronización continua en tiempo real.
Formato recomendado
El formato recomendado para esta integración es NDJSON, por su sencillez de procesamiento y su buen encaje con cargas estructuradas de registros. Como alternativa, también puede utilizarse CSV cuando resulte más adecuado para el sistema origen o para el proceso de exportación disponible.
En todos los casos, se recomienda que los ficheros utilicen codificación UTF-8 y una estructura consistente que facilite su tratamiento automatizado por la plataforma.
Recursos relacionados
Activos
Servicios de Apoyo
Documentación
Documentos para Desarrolladores
| Fecha | Título |
|---|---|
| 2026-03-31 | Presentación del modelo de integración |