Documentation for a newer release is available. View Latest

Conceptos

Ciclo de vida de la tarea

A continuación se muestra un diagrama de estados simplificado, de camino feliz, para el ciclo de vida de la tarea, con una breve explicación del ciclo de vida.

Algunos aspectos del ciclo de vida de la tarea se han omitido o no se han detallado completamente en el diagrama para mantenerlo más claro. Para profundizar en estos aspectos, revise las siguientes secciones: Creación de tareas, Asignación de tareas, Cancelación de la tarea, Revisión de ejecución de la tarea y Notificación de tarea cerrada.

happy-path-task-state-diagram

  1. Cuando se crea una tarea se inicializa con el estado "Registered". Más información sobre la creación de tareas se puede ver en la sección Creación de tareas.

  2. Una vez que la tarea ha sido asignada a un operador, transiciona a "Allocated". En el estado "Allocated", es posible volver a "Registered". Esto se detalla en la sección Asignación de tareas.

  3. Después de que un operador haya ejecutado la tarea, los resultados de la ejecución se registran en el task manager. Si la tarea se registró con approvalsRequired > 0, entonces la tarea transiciona a "In Approval"; de lo contrario, transiciona al estado terminal, "Complete".

  4. La ejecución de la tarea puede aprobarse o rechazarse. Si la tarea ha recibido menos aprobaciones de las requeridas, entonces la tarea permanece en el estado "In Approval" hasta que alcance el umbral; de lo contrario, transiciona al estado terminal, "Complete". Esto se explica con más detalle en la sección Revisión de ejecución de la tarea.

Creación de tareas

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

La creación de tareas es idempotente, lo que significa que si la misma solicitud de creación de tareas se repite varias veces, entonces solo se creará una tarea para la primera solicitud. En cada solicitud posterior, se devolverá el ID de la tarea existente. La propiedad de la solicitud que se utiliza para determinar 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 operator ID desde el estado "Registered", lo que transiciona la tarea a "Allocated".

Desde el estado "Allocated", una tarea puede reasignarse a otro operador o desasignarse. Para reasignar, se proporciona un nuevo operator ID y la tarea permanece en el estado "Allocated", aunque con un nuevo operator ID. Para desasignar una tarea, se puede proporcionar un operator ID nulo, y la tarea transiciona nuevamente a "Registered".

El siguiente diagrama muestra las posibles transiciones de estado para el aspecto de asignación.

allocation-state-diagram

  1. Se proporciona un operator ID desde el estado "Registered"; la tarea transiciona a "Allocated" con claimedBy igual al operator ID.

  2. Se proporciona un operator ID desde el estado "Allocated"; la tarea permanece en "Allocated" con claimedBy igual al nuevo operator ID.

  3. La tarea se asigna a un operator ID null; la tarea transiciona a "Registered".

Revisión de ejecución de la tarea

Si una tarea se registra con requiredApprovals > 0, entonces transicionará a "In Approval" cuando la tarea sea ejecutada. La tarea debe recibir la cantidad requerida de aprobaciones para transicionar a complete. Si una tarea es rechazada, entonces se envía de vuelta al estado "Allocated", donde puede volver a ejecutarse.

Rechazar una tarea reinicia recievedApprovals. Por ejemplo, una tarea tiene requiredApprovals == 2. Recibe una aprobación y luego es rechazada, lo que provoca que el conteo receievedApprovals se restablezca a cero. Cuando la tarea se vuelve a ejecutar, debe recibir dos nuevas aprobaciones antes de que la tarea complete.

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

Cuando la tarea está siendo ejecutada, el operador puede dejar una nota que, además de agregarse al historial de tareas, también se proporcionará en la tarea como executionNote.

approvals-state-diagram

  1. La tarea fue rechazada; la tarea transiciona de nuevo a "Allocated" donde puede volver a ejecutarse.

  2. La tarea fue aprobada; receivedApprovals se incrementa y receivedApprovals < requiredApprovals; la tarea permanece en "In Approval".

  3. La tarea fue aprobada; receivedApprovals se incrementa y receivedApprovals == requiredApprovals; la tarea transiciona a "Complete".

Cancelación de la tarea

Mientras esté en cualquier estado no terminal, una tarea puede ser cancelada. Esto transiciona la tarea al estado "Cancelled" y cierra la tarea.

cancellation-state-diagram

Notificación de tarea cerrada

Cuando la tarea alcanza un estado terminal ("Cancelled" o "Completed"), se envía una notificación de tarea cerrada al kafka topic configurado (HTM_TASK_CLOSED_NOTIFICATION). Si la tarea fue "Cancelled", la notificación de tarea cerrada contiene información sobre el task ID y el estado terminal. Si la tarea ha alcanzado el estado "Completed", también proporcionamos información sobre el resultado de la tarea y los datos del resultado.