Demostrador: Flujo de expedientes bancarios

Como venimos haciendo, hemos desarrollado otra prueba de concepto de cómo se puede trabajar con diferentes componentes de Onesait Platform: DataFlow, Flow Engine, Entidades virtuales, APIs, etc. para, de forma muy sencilla, generar expedientes bancarios para distintas entidades a partir de los datos obtenidos invocando un servicio REST.

Este demostrador lo realizaremos con un enfoque Low Code, ya que todo se creará a partir de diagramas, flujos, editores y formularios desde el Control Panel de la Plataforma. Concretamente, hemos usado el entorno de CloudLab, nuestro laboratorio de pruebas en la nube:

Descriptor del demostrador

El flujo validará los datos entrantes de distintas formas, por ejemplo, validando algunos parámetros de cada registro contra entidades virtuales o comprobando si algún parámetro necesario no está relleno.

Tras realizar las validaciones, los registros validos serán redireccionados a los distintos subflujos de inserción en función de la entidad, para completar los datos para éstas, y para almacenar los registros en la entidad que corresponda, y los expedientes descartados se almacenan en una Entidad, con un campo error que indica porque no se han podido insertar.

Finalmente, los resultados del registro de expedientes pueden verse en un Dashboard que se carga accediendo a una aplicación web que la propia Plataforma sirve, para no tener que desarrollarla desde cero, teniendo únicamente que indicar los Dashboards a los que se tendrá acceso desde el menú de la aplicación web.

A continuación podemos ver un diagrama mostrando el sistema:

¿Qué se está haciendo aquí?

En primer lugar, tenemos una API REST de un banco, la cual nos proporciona la información necesaria para generar los distintos expedientes.

Para la demostración, tenemos un Flow («startexpedientsingest») que inicia el proceso de forma manual, aun que lo podíamos hacer con un nodo cron y hacerlo temporizado cada cierto tiempo.

En este punto, hemos lanzado la ejecución, comprobando el estado del DataFlow principal. Si todo es viable, se lanza.

Estaríamos ahora en este punto del diagrama de arriba.

En el flujo principal se invoca al API REST de un banco, que nos traerá la información para la demostración. Son registros con cientos de campos donde unos cumplen los requisitos para convertirse en expedientes y otros no, y terminan almacenándose junto al error en la entidad «expedient_error».

En el diagrama vemos este componente :

Este módulo actúa como el Bus o Broker de la Plataforma. Ofrece conectores en diferentes tecnologías como Kafka, MQTT, REST, WebSockets, AMQP, etc., permitiendo que los diferentes clientes (sistemas y dispositivos) puedan comunicarse con la Plataforma de forma eficiente. Si queréis conocer más al respecto, contamos con un artículo detallado en nuestro Portal de Desarrollo.

Más abajo, en el apartado DataFlow, se especifica mejor qué hace cada componente, pero quieremos indicar que en este componente del flujo principal se está haciendo una validación de cada registro contra una Entidad Virtual, comprobando si existe el tipo de interviniente usado en el expediente en esta entidad virtual que es un catálogo de tipos de intervinientes. Hacemos esto simplemente añadiendo una caja al flujo y mapeando el campo del registro y el de la tabla.

Tras el lookup contra la Entidad, se procede a la validación. En ella, si el parámetro viene relleno, es que existe ese tipo de interviniente, y el registro sigue su camino para ser almacenado correctamente. Si no, irá a la entidad de errores con su mensaje correspondiente.

Tras pasar las validaciones, cada registro va a su subflujo correspondiente en función de si (no) cumple algún criterio de validación y de la entidad bancaria, ya que cada validación necesitará que los registros se completen o validen de forma especifica.

Con esto se da más flexibilidad ya que si se añadiese una nueva Entidad, tan sólo habría que añadir un nuevo subflujo a la salida del flujo principal. No tendremos un flujo gigantesco con toda la funcionalidad sino que lo tendremos segmentado siendo más sostenible.

Finalmente se ha creado un Dashboard que muestra la información sobre este proceso, es decir, registros creados, errores, posible filtro por días, etc. También se ha creado un API REST que permite consultar la información de los expedientes.

Componentes

A continuación podemos ver los distintos componentes que forman el demostrador:

Proyecto Web

En la Plataforma se ha desplegado un proyecto web:

Esta aplicación marco permite hacer desarrollos agiles como este, ya que tiene integrado el logueo del usuario con la seguridad de la Plataforma.

Puede usarse directamente modificando el fichero de configuración donde se indican los Dashboards que se mostrarán. Para ello, al crear el proyecto web:

Se puede marcar la opción «Deploy Frontend Project». Con esto tendremos disponible la aplicación para añadir los Dashboards a mostrar, teniendo así en pocos minutos una aplicación donde poder mostrar los Dashboards.

Además, muestra la información del usuario que ha accedido:

El Dashboard

Se ha desarrollado un Dashboard que se muestra desde el proyecto web como se veía anteriormente. Este dashboard esta desarrollado con el Dashboard Engine de Onesait Platform.

Está compuesto por distintos elementos:

Un selector múltiple de entidad, que permite filtrar los datos de los gadgets, para mostrar únicamente los valores de las Entidades que queremos:

KPI Total expedientes Entidad 2

Muestra el valor total de expedientes creados para esta entidad.

KPI Total Errores al crear Expedientes

Muestra el total de errores almacenados en la Entidad «expedient_error». Se actualiza automáticamente si se realizan cambios en la entidad.

Comparativa Total expedientes creados por entidad y proyección a un mes:

Total Errores y Total Errores a un mes

Radar por entidades que muestra la media de errores por día y expedientes creados.

Total, expedientes por día

En la gráfica de barras, el eje x muestra las fechas, y el eje y es para el total de expedientes creados para ese día. Cuenta con una serie de acciones posibles:

• Clicando sobre las barras se puede filtrar la tabla de errores a su derecha.
• Se puede utilizar el zoom activándolo con estos botones y descargar en formato imagen la gráfica.

En la gráfica de barras también se indica, para los valores mostrados, el valor máximo, mínimo y la media.

Tabla de Errores
Se muestran los expedientes no creados. Se puede filtrar los resultados escribiendo junto al icono de la lupa y pulsando «enter». La tabla también cuenta con ordenación y paginación.

Flow Engine

Se ha creado un flow que sirve de disparador del DataFlow principal. Para el ejemplo se lanza manualmente, aunque se podría temporizar o iniciar cuando llegase una llamada a un API.

DataFlows

Se han desarrollado cuatro DataFlows:

Un DataFlow principal que, dependiendo de la entidad, redirige el expediente a un subflujo de inserción u otro.

mainflowingestdata

Al iniciarse esté flujo se invoca al API REST. Este proporciona los registros con la información necesaria para crear los expedientes. Se parsea la entrada para pasar de trabajar con un String a objetos.

En este paso se valida si el tipo de interviniente usado en cada registro coincide con alguno de los almacenados en la entidad virtual «t_Interviente». Esta entidad virtual está creada a partir de una tabla de una base de datos MariaDB. Si existe, continuará el flujo.

En caso contrario, el registro erróneo se almacenará en una entidad creada para este fin, registrando el error por el que no es valido el expediente para ser creado:

En caso de que existe el tipo de interviniente, continua el flujo realizándose las siguientes validaciones por si algún campo necesario viniese vacío.

Finalmente, dependiendo del resultado de estas validaciones y del identificador de la entidad, los registros se dirigirán a un subflujo u otro:

Flujo inserción

En este subflujo se reciben los registros que no hayan dado error anteriormente y se completa la información para luego almacenar el expediente en la entidad «expedient_dest». Para el ejemplo si el campo «EXPEDIENTE.COMENTARIOS» es nulo se carga con un comentario:

Otra virtud que tiene el DataFlow de plataforma es que tiene varios modos de funcionamiento cada uno de estos flujos de datos, así podemos crear el flujo en modo desarrollo o probarlo con el modo debug. Otro modo como mostramos en la captura es el de ejecución donde podemos ver la información de las ejecuciones, summary, errors, gráficas, etc.

ENTIDADES

expedient_dest

Entidad donde se almacenan los expedientes creados.

expedient_error

Entidad donde se almacenan los expedientes que han dado algún error al intentar crearse en los DataFlow.

expedient_kpis

Entidad con datos de ejemplo para simular distintos KPIs de los expedientes.

expedient_form

Entidad que almacena los datos de los formularios que van a ser creados y que se sirven por API REST en del DataFlow principal.

t_interviniente

Entidad virtual a partir de una conexión con una base de datos MariaDB, de la cual se sacan los tipos de intervinientes.

---

Espero que os haya parecido interesante esta lectura y hayáis podido comprobar que, con Onesait Platform, se pueden construir Proyectos y Productos muy potentes desde el enfoque Low Code. Os animamos y retamos de nuevo a que os registréis como usuarios en nuestro entorno CloudLab para probar a crearse una entidad por ejemplo y mostrar el contenido en un dashboard, o crear un flujo de datos, o cualquiera de los miles de cosas que se pueden hacer y probar.

Si os surge alguna duda al respecto no dejéis de dejarnos un comentario. Además, si estáis interesados en que os enseñemos esta demostración en directo, no dudéis en contactar con nosotros para concertar una cita en nuestro correo de contacto contact@onesaitplatform.com.

---

Imagen de cabecera: Kari Shea en Unsplash.

✍🏻 Author(s)