Muestra las diferencias entre dos versiones de la página.
Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
ada:howto:sicoferp:factory:new-migracion-sicoferp:apilegacy [2024/06/07 01:04] administraidor |
ada:howto:sicoferp:factory:new-migracion-sicoferp:apilegacy [2024/06/13 16:13] (actual) 192.168.177.2 |
||
---|---|---|---|
Línea 11: | Línea 11: | ||
===== Arquitectura ===== | ===== Arquitectura ===== | ||
La API Legacy se basará en una arquitectura RESTful, siguiendo los principios de diseño de APIs REST. Esto permitirá una fácil integración con las aplicaciones legacy y los nuevos sistemas, utilizando protocolos HTTP estándar y formatos de datos como JSON. | La API Legacy se basará en una arquitectura RESTful, siguiendo los principios de diseño de APIs REST. Esto permitirá una fácil integración con las aplicaciones legacy y los nuevos sistemas, utilizando protocolos HTTP estándar y formatos de datos como JSON. | ||
+ | |||
+ | {{ :ada:howto:sicoferp:factory:new-migracion-sicoferp:arqapilegacy.png?600 |}} | ||
+ | |||
+ | A contiuación se describe el modelo utilizado de forma general: | ||
+ | |||
+ | * **LegacyApplicationPB**: Son las aplicaciones desarrolladas en Powerbuilder las cuales integran un api propia en el core que genera la información de integración posteriormente consume la url del microfrontend por medio de un método GET. | ||
+ | * **LegacyApplicationJava**: Son las aplicaciones desarrolladas en Java pero a diferencia de las anteriores si hace un registro previo de la información de integración por medio del api-legacy y por último consume la url del microfrontend por medio de un método GET. | ||
+ | * **Api Legacy Microfrontend**: Es la encargada de registrar la información de integración, encriptar y desencriptar tokens y autorizar los consumos de las aplicaciones legacy. | ||
+ | * **Microfrontend**: Es la funcionalidad front migrada a las nuevas técnologias utiliza el api-legacy para autenticar y autorizar las peticiones realizadas por las aplicaciones legacy. | ||
+ | * **EcosystemConfigWS**: Entre sus configuraciones provee un metodo que devuelve las rutas que utilizará el microfrontend. | ||
+ | * **Client**: Origen de datos del cliente (DB). | ||
===== Componentes ===== | ===== Componentes ===== | ||
Línea 68: | Línea 79: | ||
El API Legacy se integrará con las aplicaciones legacy y los nuevos sistemas de diversas maneras, abriendo un abanico de posibilidades para la migración y el desarrollo futuro. A continuación, se describen algunos de los escenarios de integración más comunes: | El API Legacy se integrará con las aplicaciones legacy y los nuevos sistemas de diversas maneras, abriendo un abanico de posibilidades para la migración y el desarrollo futuro. A continuación, se describen algunos de los escenarios de integración más comunes: | ||
- | * [[ada:howto:sicoferp:factory:new-migracion-sicoferp:apilegacy|Integración Microfrontend]] | + | * [[ada:howto:sicoferp:factory:new-migracion-sicoferp:apilegacy:microfrontend|Integración Microfrontend]] |
- | + | * [[ada:howto:sicoferp:factory:new-migracion-sicoferp:apilegacy:apipb|Integración Application Legacy PB]] | |
- | ==== Integración Microfrontend ==== | + | * [[ada:howto:sicoferp:factory:new-migracion-sicoferp:apilegacy:apijava|Integración Application Legacy Java]] |
- | El API Legacy se debe utilizar para implementar una arquitectura de microfrontend, donde cada aplicación frontend se integra con el API para autorizar el acceso a las funcionalidades que se migran. Esta estrategia facilita el desarrollo y mantenimiento de las aplicaciones frontend, ya que cada una puede ser desarrollada y actualizada de forma independiente. | + | |
- | + | ||
- | El flujo para autorizar los accesos desde aplicaciones legacy es: | + | |
- | + | ||
- | === Paso 1 === | + | |
- | Las aplicaciones legacy consumiran la url del microfrontend y enviarán un parámetro llamado legacyToken de tipo string. | + | |
- | + | ||
- | === Paso 2 === | + | |
- | El parámetro legacyToken es un string con el siguiente formato **contextClient@uuid** el cual al ser separados por el simbolo @ se obtendran 2 fragmentos. | + | |
- | + | ||
- | * **contextClient**: Código del cliente. | + | |
- | * **uuid**: token de autenticación. | + | |
- | * **separador**: Caracter de separación de los fragmentos del token legacy. Por defecto se define @ | + | |
- | + | ||
- | Ejemplo: legacyToken=bello-dev@180A072B7AC858EFE06 | + | |
- | + | ||
- | * **contextClient**: bello-dev | + | |
- | * **uuid**: 180A072B7AC858EFE06 | + | |
- | * **separador**: @ | + | |
- | + | ||
- | === Paso 3 === | + | |
- | Se debe consumir el método del api **autenticate-microfrontend-launcher** el cual puede ser consultado en la documentación de la [[#Capa de lógica de negocio|Capa de lógica de negocio]] y pasar el contextClient como token en el header y el uuid como parametro. | + | |
- | + | ||
- | Si el uuid está vigente se devolverán los parametros de sesión encriptados con el código 200. Lo que permitirá el acceso a la funcionalidad. | + | |
- | + | ||
- | {{ :ada:howto:sicoferp:factory:new-migracion-sicoferp:api-legacy1.png?600 |}} | + | |
- | + | ||
- | Si el uuid está vencido o es inválido se devolverá una excepcion con el código 500. Lo que evitará el acceso al microfrontend. | + | |
- | + | ||
- | {{ :ada:howto:sicoferp:factory:new-migracion-sicoferp:api-legacy2.png?600 |}} | + | |
- | + | ||
- | === Paso 4 === | + | |
- | Al realizar la autenticación de forma correcta se obtendra un hash que contendrá los parametros de sesión pero estarán encriptados por lo tanto se debe consumir el servicio **decrypt-legacy-secure-token** el cual recibirá 2 argumentos uno en el header llamado token el cual recibirá el contextClient y un parámetro secureToken donde se le enviará el hash obtenido del proceso de autenticación como se ve en la imagen. | + | |
- | + | ||
- | {{ :ada:howto:sicoferp:factory:new-migracion-sicoferp:api-legacy3.png?600 |}} | + | |
- | + | ||
- | El servicio devuelve un objeto json con la siguiente estructura. | + | |
- | + | ||
- | <code yaml> | + | |
- | { | + | |
- | "idOption": 1,//Identificador del Path del microfrontend | + | |
- | "tituloVentana": "Maestro Terceros",//Titulo de la opción en la aplicación legacy | + | |
- | "nitEmpresa": 800167494,//Nit de la empresa del cliente | + | |
- | "nombreEmpresa": "Uniempresa de prueba",//Nombre de la empresa del cliente | + | |
- | "codigoMempresa": 9999999999,//Código de la empresa del cliente | + | |
- | "codigoUsuario": 1,//Código del usuario en la aplicación legacy | + | |
- | "nombreUsuario": "Pepito Perez",//Nombre del usuario en la aplicación legacy | + | |
- | "login": "123456789",//login del usuario en la aplicación legacy | + | |
- | "fechaSistemaModulo": "06/06/24",//Fecha del sistema en la aplicación legacy | + | |
- | "codigoDependencia": 66//(Opcional) Código de la dependencia, solo aplica para la aplicación de presupuesto | + | |
- | } | + | |
- | </code> | + | |
- | + | ||
- | === Consideraciones === | + | |
- | + | ||
- | * El uuid es de un solo uso, de esta manera aseguramos la integridad de las integraciones y consumos de los nuevos componentes. | + | |
- | * Los parámetros desencriptado son la base para la inicialización del microfrontend. | + | |
- | * Salvo los parámetros opcionales los demás son requeridos por lo tanto se aconseja aplicar validaciones de esas propiedades al desencriptarlas. | + | |
- | * Todo consumo microfrontend es almacenado para efectos de auditoria. | + | |
[[ada:howto:sicoferp:factory:new-migracion-sicoferp|←Regresar]] | [[ada:howto:sicoferp:factory:new-migracion-sicoferp|←Regresar]] | ||