Como desarrollador, quería demostrar y compartir la facilidad de uso del proveedor de acceso a datos NTi sobre una base de datos DB2 para i, a través de un breve artículo y un interesante proyecto específico: desarrollar una API .NET capaz de comunicarse con varias bases de datos, DB2 for i en una partición IBM i, y PostgreSQL en contenedor en una Raspberry pi conectada a su vez al IBM i.
La idea es desarrollar una aplicación paralela del lado del cliente que pueda recuperar datos en formato JSON directamente desde esta API, y mostrarlos de forma dinámica, modular y moderna.
Ya he construido algunas aplicaciones front-end usando Nuxt JS, pero nunca he probado el framework Angular JS, así que esta será una buena forma de descubrir TypeScript.
Creando la API
Paso 1: Configurar el entorno de trabajo
Así que voy a empezar con el entorno ASP .NET API directamente desde Visual Studio, que ofrece una configuración lista para usar, con herramientas clave como Swagger, integradas de forma natural en el ecosistema .NET y que permiten probar la API de forma eficaz de forma nativa sin necesidad de utilizar POSTMAN.
Para poder realizar consultas SQL en cualquier base de datos, es necesario contar con el proveedor de datos (driver) adecuado, cada uno de los cuales cumple con los estándares ADO.NET, que representan un conjunto de clases diseñadas para facilitar el acceso a los datos a las aplicaciones .NET.
Esto permite manipular datos (leer, escribir, actualizar, eliminar) utilizando objetos y métodos conocidos (soporte para comandos SQL, gestión de conexiones, ejecución de transacciones, manipulación de resultados de consultas, etc.).
Así que elijo :
NTi** para DB2 for i
NPGSQL** para PostgreSQL
Estos 2 proveedores están referenciados en NuGet, la clave de licencia NTi ya está integrada en el IBM i, sólo necesito descargarlos como dependencia de mi proyecto y listo.
A continuación, instalé Dapper, un ORM ligero y de código abierto diseñado por el equipo de StackOverflow para consultar estas 2 bases de datos; la asignación automática de entidades supone un claro ahorro de tiempo.
Ahora puedo configurar operaciones CRUD y destacar la sencillez de ejecución de las consultas. En particular con NTi, que se conecta a DB2 para i sin driver, sin overlay y sin restricciones, basta con configurar la cadena de conexión en el programa.
Paso 2: Modelado de datos y configuración de servicios
Una vez integrados los proveedores de datos necesarios para mi proyecto, empiezo a trabajar en la estructura interna de la API.
Empiezo por definir los distintos modelos de datos, para asegurarme de que su tratamiento y los intercambios entre la API y las 2 bases de datos están estructurados.
Para cada base de datos, configuro servicios de conexión independientes utilizando los dos proveedores de datos mencionados anteriormente, con el fin de establecer una conexión segura y eficaz que permita a la API ejecutar consultas SQL.
DB2Service:
PGSQLService:
Una vez establecidos los modelos y servicios, puedo crear los controladores. Estos procesan las peticiones entrantes, ejecutan la lógica necesaria (CRUD) y devuelven las respuestas apropiadas a los clientes.
Solicitud GET para recuperar categorías:
Solicitud POST para añadir una nueva categoría:
Para garantizar que las peticiones HTTP se dirigen correctamente a las acciones de los controladores, he establecido un sistema de rutas preciso. Las rutas asocian URLs específicas con las acciones de los controladores, asegurando que cada petición llegue al destino especificado en la API.
Resultado de la solicitud GET en Swagger:
Esquema de solicitud API para añadir una nueva categoría (POST)
Por último, para permitir que la aplicación externa recupere datos de la API .NET, añado una configuración CORS (Cross Origin Resource Sharing) para autorizar las peticiones entre dominios de forma segura, garantizando así que la aplicación Angular pueda acceder a los recursos de la API sin violar la misma política de origen.
Con la API configurada y funcionando, ya está lista para usar y allana el camino para la siguiente etapa, la creación de la aplicación front-end.
Creación de la aplicación Angular
Paso 1: Configurar el entorno Angular
Empiezo configurando el entorno de desarrollo necesario para Angular usando Node.JS y NPM, e instalando los paquetes de Angular Cli. Con el modelo de diseño MVVM, la idea es separar la lógica de visualización de la lógica de negocio. Esta vez, estoy usando Visual Studio Code, que tiene una serie de extensiones prácticas que me permiten desarrollar más rápidamente.
Paso 2: Creación de servicios y modelos de datos.
De la misma manera que la API .NET, también creo modelos de datos TypeScript para un manejo, almacenamiento y uso más eficiente de estos datos en la aplicación.
La comunicación con la API .NET se establece a través de los servicios ofrecidos por Angular, utilizando el protocolo HTTP para intercambiar datos en formato JSON.
Así que creo diferentes servicios que actúan como puente entre la aplicación Angular y la API .NET. Cada método utiliza una URL específica, y ahora puedo llamar a los métodos correspondientes a cada servicio directamente desde cada componente de Angular.
Paso 3: Desarrollo de componentes
El propio principio e interés de Angular reside en el uso de componentes, formados por un archivo TypeScript que gestiona la manipulación de datos y la lógica de negocio, un archivo HTML para las plantillas y un archivo css o scss para el estilo. Estos componentes pueden anidarse unos dentro de otros, promoviendo la modularidad.
Al crear componentes separados para diferentes partes de la interfaz de usuario, pude llamar a los métodos definidos en los servicios de Angular para recuperar datos de la API.
Esto facilita la creación de gráficos o cálculos de complejidad variable para satisfacer necesidades específicas, al tiempo que se beneficia de la actualización dinámica de la interfaz de usuario y de tiempos de respuesta extremadamente bajos.
Creación de un gráfico de barras para recuperar el número de productos por categoría:
visual del diagrama de palos, desde mi aplicación frontal Angular:
visual de un gráfico circular que muestra las existencias de productos:
Conclusión
Este proyecto no sólo ilustra las ganancias en productividad y modularidad que ofrece el ecosistema .NET, sino que sobre todo es una demostración elocuente de la sencillez y eficacia de NTi a la hora de acceder a datos en IBM i, y de crear aplicaciones de cliente grueso.
Con una buena comprensión de los principios de la programación orientada a objetos, los estándares ADO .Net y, por supuesto, el lenguaje SQL, sea cual sea el SGBD subyacente, el desarrollo moderno y la comunicación con diversas bases de datos se vuelven realmente accesibles, fáciles y libres de restricciones.
Lo que he diseñado rápidamente es una ilustración perfecta de una de las innumerables posibilidades que ofrece nuestro proveedor de datos Nti, que pone de relieve la importancia de disponer de un acceso simplificado y rápido a los recursos de sistemas tan robustos como el IBM i. Estos recursos se convierten no sólo en accesibles, sino también en plenamente explotables para el desarrollo de aplicaciones empresariales específicas para cada necesidad, sin ninguna complejidad añadida.
La creación de una API .NET capaz de comunicarse simultáneamente con DB2 for i en una partición IBM i y con una instancia PostGreSQL contenedorizada en una Raspberry Pi conectada al IBM i ilustra claramente la versatilidad y la eficacia de nuestro proveedor de datos NTi para orquestar una comunicación perfecta combinando hábilmente recursos tradicionales y modernos.
Quentin Destrade