Layer-api-event-bus-service
Servicio con conexion directa a la base REDIS encargado del manejo de asignaciones, desasignaciones, eliminado de hashes y modificación de los mismos.
Sumario
Dependencias
Servicio Core para al actualizacion de estatus de la tarea
Servicio Core para al actualización de estatus del histórico de la tarea así como la información de los workers.
Servicio Core para la obtención de los perfiles y permisos de los workers.
Bases de datos
REDIS
Funcionalidad
El servicio de event-bus tiene múltiples funcionalidades relacionadas con el manejo de los hashes y colas en redis como lo es la edición, creación y eliminacion de estos elementos.
Para cualquiera de los 2 esquemas (Push y Pull) se puede simplificar su funcionamiento en 2 tareas: Asignación y Finalización de la tarea.
Asignaciones
El proceso de asignación es diferente para el esquema Push y el esquema Pull.
Para el esquema push la asignacion de la tarea es automatica, donde el usuario no tiene control de la tarea que se le va a asignar, mas que por el tipo ed priviegios o carcteristicas que tenga. Se hace una iteracion entre las colas de prioridad, hasta encontrar una tarea que sea acorde a el perfil.
La forma de asignación del esquema Pull es directa, es decir, el usuario elige la tarea que desea resolver y se la auto asigna.
Los movimientos que se realizan dentro de redis al hacer la asignacion son los siguientes:
- Se agrega el workerId al TaskHash de la tarea
- Se crea el WorkerHash con el id del Worker que va a contener el taskId de la tarea y el momento en que se realizo esta asignación.
- Se va a agregar un elemento a la cola BusyWorkers con el uuid del worker.
Y fuera de redis se van a actualizar los siguientes registros:
- Estatus en la tabla task_segment del layer-api-core-service
- Estatus en la tabla task del layer-api-web-service
- Estatus y data enviada en la tabla task_history del layer-api-web-service
A continuación se indagara mas en la forma de asignación de los 2 esquemas actuales dela plataforma.
Asignaciones Push
Como se menciono anteriormente la asignacion es auutomatica. El primer paso es conocer si el worker tiene una tarea preasignada. Es la jerarquia mayor, pues es una asignación manual que requiere ser resulta inmediatamente.
En caso de no existir una tarea preasignada en el WorkerHash del usuario, continua por iterar en cada una de las colas de prioridad hasta encontrar una tarea que cumpla con los siguientes requerimientos:
- El worker no tiene que estar en el workerBanList de la tarea.
- El role o el taskIdentifier (para el caso antiguo de las asignaciones) debe de estar contenido en el o los roles que tiene la tarea en su ListTaskItem
- Para el caso de clonación, debe de tener un score mayor al minimo requerido en la tarea, definido en su ListTaskItem
Si las condiciones no se cumplen continua iterando en las siguientes tareas.
En caso de si cumplirlas retorna al front el workPackage definido en el TaskHash.
Asignaciones Pull
Las asignaciónes pull comienzan entregado al usuario un workList con la información de las tareas que puede resolver de acuerdo a su perfil, que viene del ListTaskItemForBranch al consultar el layer-api-scheduler-manager-service.
Cuando tiene el id del segmento de la tarea se manda a llamar layer-api-scheduler-manager-service o el event-bus para su asignación y este retorna el id de la tarea asignada y el campo de resumen de la tarea.
Elementos que lo consumen
Swagger
link de swagger de calidad [[1]]
