Why use Kettle to publish data using the OCDS Standard? // Por qué utilizar kettle para la publicación de datos en el estándar EDCA ?

In Argentina, the National Roadwork Directorate (DNV) is responsible for improving and expanding the country’s extensive network of highways and roads – an essential body to infrastructure initiatives. In early 2019, Development Gateway (DG) began collaborating with DNV to publish its contracting data using the Open Contracting Data Standard (OCDS) through an open data portal.

Using OCDS, organizations like DNV can increase public procurement transparency and allow external users to analyze the available data.

As we’ve written before, OCDS enables data publication by defining a common data model. In using OCDS to publish data, a common challenge is presented early in the process – when the development team analyzes the available data sources, and decides how to extract that data and convert it to OCDS format. Today, we’re sharing our thought process behind choosing Pentaho Data Integration (Kettle PDI) to accomplish the job, and a few lessons we learned in the process.

Together with the DNV team, DG took into consideration that DNV’s data comes from three different sources. Additionally, DNV plans to modernize the databases that would be sources for the OC data portal. To accommodate this, we determined that the solution must be flexible and easily adaptable to new changes.

We needed a robust, easy-to-configure ETL (extraction, transformation and loading) tool, which would allow users to make changes without affecting the final product – a JSON object holding information across all phases of the roadworks contracting process in Argentina, built using DG’s open contracting tool, the OC Explorer.

We prioritized our approach to tackling the ETL function, deciding which tool would best serve our work with DNV. After evaluating several open-source options, we decided to implement a solution with Kettle PDI, because:

• It would allow us to extract data from several databases and documents.
• We would be able to perform data migration both manually and at specific time intervals aligned with client needs.
• The source code would be easily maintained by the DNV team beyond the length of the contract.
• It would serve our open-source tool needs.

As shown in the DNV portal architecture figure below, the Kettle PDI tool is part of the backend of the ETL process.

Figure 1: The DNV portal’s technical architecture

We used Spoon, a graphic visualization tool, to create the chart below. Spoon allows us to visualize Kettle PDI processes in an easy-to-understand way. Each green arrow pointing to a new square is known as a transformation – or the process through which data flows in an orderly way to reach the final product. For the DNV portal, the ETL tool allowed us to link together multiple transformations to arrive at the final JSON object with all the necessary data.

Figure 2: A series of transformations to arrive at the final product

For each transformation performed, multiple different operations can also occur concurrently. For example, the system can perform several operations at the same time – it can read variables from a configuration file, obtain data from a database, transform data formats using javascript, save data in different formats, make a REST call to a web service, and write a log file.

In any system, it’s essential that migration tasks are done effectively. For the DNV portal, effective migration ensures that final data publication complies with the OCDS standard – hundreds of fields need to be mapped from the DNV’s databases to the system’s repository, in OCDS format. The mapping must also be valid according to the OCDS release schema, which follows the standard and defines data content and structure.

In using Kettle PDI to develop the DNV portal, we ensured the tool was most beneficial to our goals and intended outcomes, gathering lessons learned along the way. Among others, a few benefits Kettle PDI provided were:

• With Kettle PDI, data extraction is very easy to execute – including using database access options using Java Database Connectivity (JDBC) and other source files. Because DNV’s data comes from several disparate sources, flexible data extraction capability was essential.
• The Kettle PDI configuration is fully customizable through an XML file. This makes it easy to follow, and allows it to adhere to customer security policy.
• Regarding data transformation, we were able to quickly solve minor challenges in saving the data in our non-relational database (the NoSQL repository of our application) directly by using Javascript.
• After the initial OCDS mapping was done and the tool development began, the client requested changes in the mapping, Kettle PDI allowed us to apply OCDS mapping changes quickly and easily.  
• By using the Spoon graphical tool, DNV team members can maintain and change the ETL files themselves, ensuring a long and useful life for the system.

As our work with Vialidad continues and we’ve launched the finished platform, our work with Kettle PDI has been highly beneficial. Having used this tool in conjunction with the OC Explorer has allowed us to create a robust and maintainable application for the DNV portal using the OCDS standard. 

Moving forward, we recommend that other organizations explore using Kettle PDI to publish data under the OCDS standard – to continue building effective systems, knowledge around different technologies, and a Kettle community of practice within our space.

_____________________________________

En Argentina, la Dirección Nacional de Vialidad (DNV) es responsable de mejorar y ampliar la red de carreteras y caminos del país, es un cuerpo esencial para las iniciativas de infraestructura en el país. A principios de 2019, Development Gateway (DG) comenzó a colaborar con la DNV para publicar sus datos de contratación pública utilizando el Estándar de Datos de Contrataciones Abiertas (EDCA) a través de un portal de datos abiertos.

Mediante el uso del estándar EDCA, organizaciones como la DNV pueden aumentar la transparencia en las contrataciones públicas y permitir a usuarios externos analizar los datos disponibles.

Como hemos escrito anteriormente, el estándar EDCA permite la publicación de datos definiendo un modelo de datos común. Cuando se utiliza el estándar  EDCA  para publicar datos, un desafío común se presenta al principio del proceso: el equipo de desarrollo debe analizar las fuentes de datos disponibles y decidir cómo extraer los datos y convertirlos al formato EDCA. Hoy, compartimos nuestro proceso de pensamiento detrás de nuestra decisión de utilizar Pentaho Data Integration (Kettle PDI) para la extracción y conversión de datos así como algunas lecciones que aprendimos en el proceso.

Junto al equipo de la DNV, DG tomó bajo consideración que los datos de la DNV provienen de tres fuentes diferentes y que la DNV planea modernizar en el corto plazo las bases de datos que fueron utilizadas para desarrollar el portal de datos abiertos. Para responder a estas variables, determinamos que la solución tenía que ser flexible y fácilmente adaptable a los nuevos cambios. Necesitábamos una herramienta ETL (extracción, transformación y carga) robusta y fácil de configurar, que permitiera a los usuarios realizar cambios sin afectar el producto final: un objeto JSON que contiene información en todas las fases del proceso de contratación de obras viales en Argentina, construido utilizando la herramienta de contratación abierta de DG, el OC Explorer.

Luego de evaluar la realización de una herramienta para migrar los datos y hacer un análisis de varias herramientas open source para realizar el proceso ETL, decidimos implementar una solución con Pentaho Data Integration(Kettle PDI). Los motivos que nos llevaron a elegir este software fueron los siguientes:

• Teníamos múltiples bases de datos y documentos de los cuales extraer información.
• La migración de los datos hacia nuestra aplicación debería poder realizarse tanto en forma manual como automáticamente cada ciertos intervalos de tiempo.
• Una vez terminado el contrato con el cliente, el código fuente debería ser fácilmente mantenible por el área de sistemas de la DNV.
• La herramienta a utilizar debía ser open source.

En la siguiente imagen se puede ver un diagrama de la arquitectura del portal DNV y cómo la herramienta Kettle PDI forma parte del backend para el proceso de ETL.

Figura 1: Arquitectura del portal de la DNV

Utilizamos Spoon, una herramienta de visualización gráfica para crear el cuadro a continuación. Spoon permite visualizar los procesos Kettle PDI de una manera fácil de entender. Cada flecha verde que apunta a un nuevo cuadrado se conoce como transformación, o el proceso a través del cual los datos fluyen de manera ordenada para llegar al producto final. Para el portal de la DNV, la herramienta ETL nos permitió vincular múltiples transformaciones para llegar al objeto JSON final con todos los datos necesarios.

Figura 2: Varias transformaciones para crear el producto final.

Para cada transformación realizada en Kettle PDI se pueden realizar múltiples operaciones en paralelo, tales como: leer variables de un archivo de configuración, obtener datos de una base de datos, transformar datos de un formato a otro mediante javascript, guardar los datos en distintos formatos, realizar una llamada REST a un web service o escribir un archivo de log.

En todo sistema, es esencial que las tareas de migración se realicen de manera efectiva. Para el portal de la DNV, la migración efectiva garantiza que la publicación final de datos cumpla con el estándar EDCA: cientos de campos deben mapearse desde las bases de datos de DNV al repositorio del sistema. Dicho estándar requiere que ese mapeo sea válido conforme a un “release schema” que es el documento que define cada uno de esos datos, tanto en su contenido como en su estructura.

Al usar Kettle PDI para desarrollar el portal DNV, nos aseguramos de que la herramienta fuera beneficiosa para nuestros objetivos, durante la implementación recolectamos las lecciones aprendidas. Algunos de los beneficios que Kettle PDI nos proporcionó fueron:

• Con Kettle PDI, la extracción de datos es muy fácil de ejecutar, incluido el uso de opciones de acceso a la base de datos mediante Java Database Connectivity (JDBC) y otros archivos fuente. Debido a que los datos de DNV provienen de varias fuentes dispares, la capacidad flexible de extracción de datos era esencial.
• La configuración de Kettle PDI es totalmente personalizable a través de un archivo XML. Esto facilita su seguimiento y nos permitió cumplir con la política de seguridad del cliente.
• Con respecto a la transformación de datos, pudimos resolver rápidamente desafíos menores que se presentaron al guardar los datos en nuestra base de datos no relacional (el repositorio NoSQL de nuestra aplicación) mediante el uso de Javascript.
• Después de que se realizó el mapeo inicial EDCA y comenzamos el desarrollo de la herramienta, el cliente solicitó cambios en el mapeo, Kettle PDI nos permitió aplicar cambios al mapeo EDCA de manera rápida y fácil.
• Al usar la herramienta gráfica Spoon, los miembros del equipo de DNV pueden mantener y cambiar los archivos ETL ellos mismos, asegurando una vida útil larga para el sistema.

El uso de Kettle PDI  junto con el OC Explorer nos ha permitido crear una aplicación robusta y fácil de mantener para el portal DNV utilizando el estándar EDCA.

En el futuro, recomendamos que otras organizaciones exploren el uso de Kettle PDI para publicar datos bajo el estándar OCDS para continuar construyendo sistemas efectivos y para crear una comunidad de práctica de Kettle dentro de nuestro comunidad EDCA.