+4
Planned

Import groups process

Juan Francisco Babío Casal 5 months ago updated by Saray Renilla Lamas 3 months ago 4

In terms of improving the group import process in NetexCloud, I wish to flag on what happened in the pre-production environment after launching an import of 64 groups:

The summary perceived by the end user is as follows:

slow process: total time in accomplishment of all the work 55 minutes, for 64 registers... What will happen with 100?

Unreliability in what the screen says: the import was done in the cloud instantly and 62 groups were created in the LMS Pack in the first minute. The remaining 2 groups took 54 minutes to propagate.

After reviewing the process with the parties, I summarize the operation that currently follows:

- For each cloud group create the group in database and create a message in the queue to send the info to central

- A processor of the queue takes the message and generates request to central (I don't know if it makes checks before launching the creation operation)

- Central collects the request and generates the group in database.

Problem that arose in this import:

In central deadlocks are produced due to possible multiple requests for several threads from the cloud.

Proposal for improvement:

- Instead of generating X messages in a queue, it would be more logical to send all the information collected in a single message. If this fails, it will be reattempted later.

- Each platform manages the information at its own convenience, which is why it requires it to implement a web service so that it can receive the information it needs.

Comments

- Communications between platforms the fewer requests there are between them the faster the communication between them.

    Answer

    Answer
    Planned

    ES

    Desafortunadamente este es un caso que afecta tanto a nuestro componente (Gestion de Usuarios) como a la plataforma que recibe la operación masiva.

    El caso del borrado se ha puesto en conocomiento de dicha aplicación. Conjuntamente se ha llegado a la conclusión de que se inroducirá una mejora en la funcionalidad para permitir el borrado de grupos que tengan hijos o elementos secundarios y así agilizar la operación de borrado. Esta mejora se encuentra en fase de desarrollo.

    La creación de grupos de manera masiva donde la esctructura donde el orden no sea algo imprescindible todavía no ha pasado a desarrollo ya que todavía no ha sido analizada por ambos componentes.

    En cualquier caso os mantendremos informados del progreso de ambas mejoras.

    Saludos,

    Saray

    EN

    Unfortunately, this case affects both our components (User Management) and the platform that receives the massive operation.

    The case of deletion has been brought to the attention of this application. It has been concluded that an improvement in the functionality will be introduced to allow groups deletion that have children or secondary elements and thus speed up the deletion operation. This improvement is in the development phase.

    Creation of groups in a massive way where the order/structure is not something essential has not yet passed to development since it has not yet been analyzed by both components.

    In any case we will keep you informed of the progress of both improvements.

    Regards,

    Saray

    Tras trabajar el árbol de organización de grupos definitivo de nuestro cliente (6200 grupos distribuidos en 5 ó 6 niveles) hemos detectado que actualmente no es viable hacer una importación masiva de todos los grupos a través de cloud, ya que es imprescindible que el orden de las operaciones de creación o borrado (en este caso central) deben ser procesadas en orden:

    • En el caso de la creación de la estructura de grupos: primero los padres y luego los hijos.
    • En el caso del borrado de grupos: primero las hojas y luego los padres de esas hojas afectadas.

    Actualmente, en el caso de central hemos superado el caso desarrollando un proceso propio de integración que lance las operaciones tanto de creación como de borrado en su debido orden y de forma secuencial.

    Este problema a surgido con central ya que es el único aplicativo que tiene multiorganización y trabaja con jerarquía de grupos. Por el momento esta problemática no se ha detectado en el resto de aplicativos.

    Answer
    Planned

    ES

    Desafortunadamente este es un caso que afecta tanto a nuestro componente (Gestion de Usuarios) como a la plataforma que recibe la operación masiva.

    El caso del borrado se ha puesto en conocomiento de dicha aplicación. Conjuntamente se ha llegado a la conclusión de que se inroducirá una mejora en la funcionalidad para permitir el borrado de grupos que tengan hijos o elementos secundarios y así agilizar la operación de borrado. Esta mejora se encuentra en fase de desarrollo.

    La creación de grupos de manera masiva donde la esctructura donde el orden no sea algo imprescindible todavía no ha pasado a desarrollo ya que todavía no ha sido analizada por ambos componentes.

    En cualquier caso os mantendremos informados del progreso de ambas mejoras.

    Saludos,

    Saray

    EN

    Unfortunately, this case affects both our components (User Management) and the platform that receives the massive operation.

    The case of deletion has been brought to the attention of this application. It has been concluded that an improvement in the functionality will be introduced to allow groups deletion that have children or secondary elements and thus speed up the deletion operation. This improvement is in the development phase.

    Creation of groups in a massive way where the order/structure is not something essential has not yet passed to development since it has not yet been analyzed by both components.

    In any case we will keep you informed of the progress of both improvements.

    Regards,

    Saray