Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

INTRODUCCIÓN

Se ha desarrollado una prueba de concepto de cómo se puede trabajar con los componentes dataflow, flow engine, entidades virtuales, apis,… de la plataforma Onesaitplatform para de forma muy sencilla generar expedientes bancarios para distintas entidades a partir de los datos obtenidos
invocando un servicio rest.

Esto lo realizaremos con un enfoque low code, ya que todo se creará a partir de diagramas, flujos , editores y formularios desde el Controlpanel de la Onesait platform, esta construida sobre el laboratorio

https://lab.onesaitplatform.com/controlpanel

Continuando con el 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 estas y almacenar los registros en la entidad que corresponda, 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.

Aquí os ponemos un diagrama, mostrando el sistema.

¿Qué se está haciendo?

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 demo 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, se comprueba el estado del dataflow principal si 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 y nos trae la información para la demo. 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 un 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,… permitiendo que los diferentes clientes (sistemas y dispositivos) puedan comunicar con la plataforma de forma eficiente, en el siguiente enlace tenemos más informción sobre él.

https://onesaitplatform-es.refined.site/space/DOC/2215907410/Un+Vistazo+al+Digital+Broker

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, esto lo hacemos 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, la cual si el parámetro viene relleno es que existe ese tipo de interviniente y el registro sigue su camino para ser almacenado correctamente sino pues 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 una 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 y añadiéndolo 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, se puede filtrar por días,...

También se ha creado un api rest que permite consultar la información de los expedientes.

  • No labels