Desarrollo múltiple identifier y su impacto en la operación.

Modificado el Lun, 29 Ago, 2022 a 6:21 P. M.

 

¿Qué fue lo que se hizo?

Con respecto al ticket: RKM-25070 se ha realizado la eliminación de los índices y restricción UNIQUE de los campos identifier y email de los modelos User y Account.

Esto permite que se puedan crear usuarios con un mismo identifier entre las diferentes empresas sin ocasionar problemas o errores de sincronización entre los servicios del monolito y el master de personas. El índice y restricción a nivel de base de datos sigue existiendo por el lado del master de personas, para evitar la duplicidad de identifiers, correos y nombres de usuario en contexto de una empresa singular.

 

¿Cuál fue el impacto?

A nivel tecnológico: Resultaron afectados los productos que habitan en el monolito de Rankmi, de los cuales se encuentran:

  • Performance (Desempeño)

  • Satisfaction (CSI)

  • Engagement (Clima)

  • Talent (Talento)

  • Transversal (Servicios transversales entre los mismos productos)

A nivel operacional: El cambio es mínimo, ya que, se realizaron todas las modificaciones correspondientes para filtrar adecuadamente los usuarios en la base de datos monolítica. Con esto, automáticamente las búsquedas por identifier se realizaran en el contexto de la empresa en la que está activa la sesión.

 

No deberían aparecer más casos de error por duplicación de identifier y correos entre empresas, por lo que, el protocolo por el canal de Slack "duplicados", que consiste en: Contactar a un CSM para desactivar al usuario duplicado en su antigua empresa y poder crearlo en otra, ya no sería necesario.

 

La restricción de unicidad sigue funcionando para todas las formas de cargar usuarios (Master de personas, API, integraciones), para evitar crear usuarios con un mismo identifier, correo o nombre de usuario en la misma empresa.

 

El cambio no causa impacto en los sub-dominios, login u otras funcionalidades de Rankmi a nivel de usuarios.

 

¿Cuál es el beneficio?

 Se habilita la carga de usuarios a través del master de personas, para crear usuarios con un identifier similar a alguno creado previamente en otra empresa. Por lo que ya no sería necesario deshabilitar los usuarios para crearlos en otra empresa.

 

Esto beneficia a los procesos de integración automática e importación de usuarios, ya que, al quitar una capa de complejidad que son estas validaciones transversales entre empresas desde el master de personas, los procesos pueden completarse con menos errores, de forma más rápida y consumiendo menos recursos (memoria, tiempo de uso de base de datos). 

 

Los errores que serán registrados en los resumen de ejecución, sólo contendrán los errores específicos de creación/actualización en el contexto de la empresa, generando menos confusión y agilizando la implementación de cambios.

 

 

En resumen

  • El cambio a nivel de operaciones es mínimo, sólo se permite la opción de cargar usuarios con un mismo identifier en otra empresa desde el master de personas e integraciones sin necesidad de deshabilitar usuarios.

  • La restricción de unicidad para el identifier, email y username sigue funcionando, pero a nivel de empresa.

  • El cambio no causa impacto en los sub-dominios, login u otras funcionalidades de Rankmi a nivel de usuarios.

 

¿Le ha sido útil este artículo?

¡Qué bien!

Gracias por sus comentarios

¡Sentimos mucho no haber sido de ayuda!

Gracias por sus comentarios

¡Háganos saber cómo podemos mejorar este artículo!

Seleccione al menos una de las razones
Se requiere la verificación del CAPTCHA.

Sus comentarios se han enviado

Agradecemos su esfuerzo e intentaremos corregir el artículo