Conceptos

Ciclo de Vida de la Tarea

Un camino simplificado y exitoso,state El diagrama del ciclo de vida de la tarea se muestra a continuación, con una breve explicación del ciclo de vida.

Algunos aspectos del ciclo de vida de la tarea han sido omitidos o no se han elaborado completamente en el diagrama para mantenerlo más limpio. Para un análisis más profundo de estos aspectos, revise las siguientes secciones:[_task_creation], Asignación de Tareas, [_task_cancellation], [_task_execution_review] y Notificación de Cierre de Tarea.

happy-path-task-state-diagram

  1. Cuando se crea una tarea, se inicializa con el "Registrado" state. Puede ver más sobre la creación de tareas en el [_task_creation] sección.

  2. Una vez que la tarea ha sido asignada a un operador, transiciona a "Asignada". En el "Asignado" state, es posible volver a "Registrado". Esto se elabora en el Asignación de Tareas sección.

  3. Después de que un operador haya ejecutado la tarea, los resultados de la ejecución se registran con el task manager. Si la tarea fue registrada con approvalsRequired > 0, entonces la tarea se transfiere a "En Aprobación", de lo contrario se transfiere al terminal state, "Completo".

  4. La ejecución de la tarea puede ser aprobada o rechazada. Si la tarea ha recibido menos aprobaciones de las que requiere, entonces la tarea permanece en "En Aprobación".state hasta que haya alcanzado el umbral, de lo contrario, transiciona al terminal state, "Completo". Esto se explica con más detalle en el [_task_execution_review] sección.

    === Creación de Tareas

La creación de tareas requiere algunos parámetros de entrada que se definen en Human Task Manager API.

La creación de tareas es idempotente, lo que significa que si la misma solicitud de creación de tarea se reproduce varias veces, entonces solo se creará una tarea para la primera solicitud. En cada solicitud subsiguiente, se devolverá el ID de la tarea existente. La propiedad de la solicitud que se utiliza para determinar las solicitudes repetidas es idempotencyKey.

Al crear una tarea, el usuario puede proporcionar posibles resultados de esa tarea.

Asignación de Tareas

Las tareas solo pueden ser ejecutadas por el operador que ha reclamado la tarea. La asignación se realiza inicialmente proporcionando un ID de operador del "Registrado" state que transfiere la tarea a "Asignada".

Desde el "Asignado" state, una tarea puede ser reasignada a otro operador o desasignada. Para reasignar, se proporciona un nuevo ID de operador y la tarea permanece en "Asignada".state, aunque con un nuevo ID de operador. Para desasignar una tarea, se puede proporcionar un ID de operador nulo, y la tarea vuelve a la estado de "Registrada".

El diagrama a continuación muestra las posibles state transiciones para el aspecto de asignación.

allocation-state-diagram

  1. Se proporciona un ID de operador desde el "Registrado" state, la tarea pasa a "Asignada" con claimedBy igual al ID del operador.

  2. Se proporciona un ID de operador desde el "Asignado" state, la tarea permanece en "Asignada" con claimedBy igual al nuevo identificador de operador.

  3. La tarea se asigna a un null ID de operador, la tarea pasa a "Registrado". === Revisión de Ejecución de Tareas

Si una tarea está registrada con requiredApprovals > 0, luego pasará a "En Aprobación" cuando se ejecute la tarea. La tarea debe recibir la cantidad requerida de aprobaciones para pasar a completada. Si una tarea es rechazada, se envía de vuelta a "Asignada" state, donde puede ser reejecutado.

Rechazar una tarea restablece receivedApprovals. Por ejemplo, una tarea tiene requiredApprovals == 2. Recibe una aprobación y luego es rechazada, causando el receievedApprovals el conteo debe ser restablecido a cero. Cuando la tarea se reejecute, debe recibir dos nuevas aprobaciones antes de que la tarea se complete.

Si possibleOutcomes se proporciona, entonces al ejecutar una tarea, el operador debe seleccionar uno de los resultados proporcionados. Si possibleOutcomes no se proporciona, entonces el resultado de la ejecución no puede ser proporcionado por el operador.

Cuando se está ejecutando la tarea, el operador puede dejar una nota que-además de ser añadido al historial de tareas-también se proporcionará sobre la tarea como un executionNote.

approvals-state-diagram

  1. La tarea fue rechazada, la tarea regresa a "Asignada" donde puede ser reejecutada.

  2. La tarea fue aprobada,receivedApprovals se incrementa y receivedApprovals < requiredApprovals, la tarea permanece en "En Aprobación".

  3. La tarea fue aprobada,receivedApprovals se incrementa y receivedApprovals == requiredApprovals, la tarea pasa a "Completo". === Cancelación de Tareas

Mientras esté en cualquier no terminal state, se puede cancelar una tarea. Esto transfiere la tarea a "Cancelada" state y cierra la tarea.

cancellation-state-diagram

Notificación de Cierre de Tarea

Cuando la tarea alcanza un terminal state("Cancelado" o "Completado"), se envía una notificación de cierre de tarea a la configuración kafka tema (HTM_TASK_CLOSED_NOTIFICATION). Si la tarea fue "Cancelada", la notificación de cierre de la tarea contiene información sobre el ID de la tarea y el terminal.state. Si la tarea ha alcanzado "Completada" state, también proporcionamos información sobre el resultado de la tarea y los datos de resultado.