Realizar pruebas de concepto para comunicación entre root y mf

[diagutierrezro]

Se requiere realizar diferentes pruebas de concepto donde se prueben las diferentes opciones según lo investigado en #237, la idea general es que se envíe información (por ahora no se sabe en concreto que información ni la forma en la que se envíe) desde el root y el mf la pueda detectar, puede ser información como nombre del sistema, un json con un posible listado de Apis, etc.

Importante ir documentando en el issue las pruebas realizadas y los resultados obtenidos aún si la prueba no fue exitosa.

Sub Tareas

• [ ] Pruebas de concepto realizadas.
• [ ] Documentar issue con pruebas de concepto realizadas.

Criterios de aceptación

• [ ] Pruebas realizadas.
• [ ] Documentación realizada.

Requerimientos

No aplica

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias están identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [ ] Desarrollo en local.
• [ ] Push en Feature.
• [ ] Pruebas locales (funcionales).
• [ ] PR a Develop.
• [ ] Criterios de aceptación cumplidos.
• [ ] Documentación de issue realizada.
• [ ] Aprobada por SM/Líder técnico.

[Skyrus1203]

ACTUALIZACIÓN 12/11/24

Se inicia con las pruebas del método que involucra custom props de single SPA, el cual consiste en definir estos en el root config (obviamente del root) y enviar estos props a la ruta del microcliente que se desee. Este método asegura que sólo se envíe esta información al micro cliente deseado y no a todos los microclientes del mismo dominio. así para realizar este proceso son necesarios los siguientes cambios:

En el root config establecer en la variable de data un arreglo de props en el que se incluyen las previamente ya establecidas variables de entorno y nuestra información personalizada:

Y en el microfrontend-layout.html se reemplaza en props el "environment" previo por "props" que es el nombre del arreglo definido en data:

Como se ve sólo se realiza este cambio en el micro cliente de auditoria que es al cual queremos enviarle la información.

Y desde el microfont end de auditoria esta información se puede rescatar desde el app.component.ts (por el momento) de la siguiente manera:

Sin embargo al momento de realizar la prueba la consola del navegador arroja el siguiente error:

Se está buscando el modo de resolver este error

[Skyrus1203]

ACTUALIZACIÓN 13/11/24

Se realizaron las pruebas de dos métodos:

Local Storage:

La implementación es sencilla y es accesible desde cualquier parte del micro cliente de auditoria, sin embargo la información que se guarde aquí es accesible desde cualquier micro cliente del mismo dominio.

Primero se realiza el guardado de la información en el local storage desde el Root de Oikos en el root config:

Luego desde el componente de auditoría en el ngInit se rescata la información y se imprime en consola:

Custom Events:

En esta aproximación se tiene más control del acceso a la información, ya que del modo en que se implementó se buscó que sólo el microcliente de auditoría tuviese acceso a la información que se quería enviar. Para lograr esto se hizo lo siguiente:

1. En el ngInit del componente de auditoría se creó un evento personalizado llamado appMounted con una carga de información indicando el nombre del microcliente:

2. En el root de Oikos, dentro del root-config se crea un evento personalizado que espere a que se active el evento appMounted y a partir de ahí compare el contenido, y si este coincide con el nombre del microcliente entonces envía la información que se desea compartir:

3. Luego en el componente de auditoría se crea un event listener que escuche al evento del root y en este caso imprima en consola la información que se envía desde allá:

Custom props

En cuanto el uso de los Custom props no se ha podido encontrar la forma de hacerlo funcionar aún, ya que o bien al no enviar en los props el environment el mf de auditoría se rompe, o si se envía el environment en el prop como si fuese un diccionario (para poder agregar los custom props) no carga todo correctamente, por ejemplo la imagen de oikos.

Se está tratando de enviar la información dentro del mismo environment y rescatarla de algún modo desde el mf de auditoría pero aún no se ha tenido éxito