Arquitecturas de sistemas¶
La publicación de datos OCDS involucra la creación de un proceso de conversión. Como un proceso ETL, los datos deben de extraerse de una o más fuentes, convertirse y servirse o almacenarse.
Este proceso necesita una arquitectura adecuada para soportarlo. Su diseño depende de varios factores:
Si los sistemas existentes pueden actualizarse o si es necesario crear nuevos sistemas,
El número y la naturaleza de las fuentes de datos,
Los recursos técnicos que dispone el publicador, como las capacidades de almacenamiento y procesamiento. Esto incluye la disponibilidad de personal técnico para mantener los sistemas nuevos y actualizados.
Otras consideraciones que afectan el diseño son:
Los documentos OCDS individuales para cada proceso deben estar disponibles en URLs persistentes únicas.
La descarga masiva en formatos JSON, CSV (y si es apropiado, en Excel) debe estar disponible. Estos archivos se deben segmentar de acuerdo a uno o más criterios, como períodos de tiempo.
Los usuarios deben de poder localizar las colecciones de registros y entregas que necesiten.
Esta guía describe algunos enfoques de diseño con sus ventajas y desventajas. Esta no es una lista exhaustiva, pero puede usarse para informar el diseño de un sistema de publicación.
Transformación bajo demanda desde las fuentes de datos¶
En este escenario, los datos de cada fuente se convierten al formato OCDS bajo demanda. Los datos OCDS no se almacenan, sino que se crean cada vez que un usuario o un tercero invoca el proceso de conversión. Este es el camino más fácil cuando una única fuente gestiona los datos para todos los procesos de contratación. Pero implica añadir un módulo de conversión OCDS.
Una API hace la transformación de los datos cada vez que recibe una petición.
El módulo de conversión produce entregas y/o registros OCDS envueltas en paquetes.
Este enfoque no necesita espacio de almacenamiento adicional. Aunque es posible que no se pueda proporcionar URL persistentes para los registros, ni un historial de cambios para cada proceso.
La guía de lanzamientos fáciles explica cómo lograr una implementación conforme al OCDS cuando no es posible proporcionar un historial de cambios completo.
Las descargas masivas pueden ser proporcionadas como parte de la API. Las consultas en vivo pueden estresar a las fuentes de datos si necesitan analizar grandes porciones de datos.
Almacenamiento OCDS separado¶
En los escenarios que siguen, un componente de middleware convierte y almacena los datos en formato OCDS. Esto tiene algunas ventajas:
Es posible fusionar y centralizar datos de más de una fuente de datos en un almacén de datos único.
Puede aliviar las fuentes de datos de consultas costosas.
Puede permitir la generación del historial de cambios para cada proceso de contratación.
Por otro lado, hay un costo de mantener un almacenamiento de datos separado. En estos escenarios, asumimos que una API proporciona el acceso a datos OCDS.
Los publicadores deben considerar cómo almacenar datos OCDS. Los registros son inmutables, por lo que pueden almacenarse tal como están, pero las entregas cambian con el tiempo. El proceso puede crear entregas en cada llamada a la API, o almacenarlas y actualizarlas cada vez que se crea un nuevo registro. La API necesita devolver datos OCDS envueltos en un paquete de entrega o registro. Por lo general, no es necesario almacenar datos OCDS empaquetados, ya que los datos del paquete se pueden generar en tiempo real.
La guía entregas y registros describe las entregas y registros del OCDS y sus diferentes componentes.
Extracción y Conversion¶
En este escenario, un proceso automatizado extrae datos de las fuentes de datos al sistema de middleware. El middleware realiza la conversión a OCDS y mantiene un almacén de datos en formato OCDS.
El beneficio clave de este enfoque es que el sistema de middleware puede almacenar el historial de cambios. Esto es especialmente bueno cuando las fuentes de datos no mantienen datos históricos.
Este enfoque puede implicar algunos cambios en las fuentes de datos para permitir que el middleware extraiga datos. El sistema de middleware fusiona y centraliza los datos en un solo lugar.
Para agregar más fuentes de datos, el módulo de conversión OCDS debe actualizarse para extraer datos de la(s) nueva(s) fuente(s).
Una decisión importante en la implementación es la frecuencia con la que se extraen datos. Si la frecuencia es baja, existe el riesgo de perder el detalle de los cambios individuales.
Una alternativa al mecanismo pull (extraer) es utilizar un mecanismo push (empujar) en cada fuente de datos. Los eventos específicos o los cambios en los datos desencadenan el extraer datos al middleware. Este enfoque puede mitigar el riesgo de perder cambios individuales. Pero esto podría implicar mayores modificaciones en la(s) fuente(s) de datos.
European Dynamics desarrolló un sistema de contratación electrónica con un enfoque similar para la producción de OCDS. El sistema fue construido para la Agencia de Contratación Pública de Zambia.
Conversión y "push"¶
Este escenario es una combinación de los dos escenarios anteriores. Las fuentes de datos realizan la conversión de datos a formato OCDS. Envían los datos convertidos a un middleware, que mantiene un almacén de datos en formato OCDS. Una API en el sistema de middleware sirve los datos OCDS.
Este enfoque coloca la carga de la conversión de datos en las fuentes de datos. Sin embargo, podría ser una solución para los publicadores con una única fuente de datos que no almacena el historial de cambios.
Este enfoque también podría ser adecuado para combinar datos de muchas fuentes de datos. Cada fuente se convierte en un publicador de OCDS. El middleware se vuelve menos complejo ya que solo ingiere datos en un solo formato.
El sistema OpenProcurement adoptó un enfoque similar. Este sistema se desarrolló en Ucrania y es la base de la plataforma Prozorro. Prozorro utiliza bloques centrales OCDS como base para los modelos de las fuentes de datos.
Una variante en este escenario puede ser almacenar archivos en un sistema de archivos accesible desde la web, como se muestra a continuación. Una invocación periódica del módulo de conversión actualiza el sistema de archivos.
El sistema de archivos garantiza que cada documento OCDS tenga una URL persistente para el acceso. Una desventaja puede ser que el volumen de datos crezca rápidamente, ya que los archivos planos pueden ocupar un espacio considerable. El sistema de archivos puede proporcionar un historial de cambios siempre y cuando los registros nunca se sobrescriban. Las descargas masivas pueden generarse periódicamente y almacenarse en el sistema de archivos. Los registros pueden ser imposibles de producir si hay más de un sistema.
Importación manual¶
En este escenario, un sistema de middleware se encuentra entre las fuentes de datos y la API.
Los datos se exportan manualmente desde las fuentes de datos a los archivos. Los archivos se cargan en el sistema de middleware, que convierte los datos a OCDS. El sistema almacena los datos en formato OCDS.
Una desventaja de este enfoque es el potencial de fallas. Los archivos de entrada pueden estar dañados o tener formatos inesperados debido a cambios o errores en las fuentes de datos.
Hay un ejemplo documentado de este enfoque en el trabajo que hizo Development Gateway en Vietnam.
Consideraciones adicionales¶
Al diseñar una arquitectura, los publicadores deben considerar lo siguiente:
** Endpoints de búsqueda **. Una API puede proporcionar más que registros y entregas individuales. Los endpoints ayudan a filtrar datos por diferentes parámetros, como proveedores y tipos de productos. Otra consideración es proporcionar formatos alternativos, como CSV y datos de Excel. Esto es importante para los usuarios que están más familiarizados con las hojas de cálculo.
Documentos. OCDS incluye la publicación de documentos. A menudo, los sistemas se vinculan a documentos en plataformas externas, donde se pueden dar enlaces rotos. Los mejores sistemas asegurarán que los documentos se archiven pero aún estén disponibles.