Bulk Acciones de Tarea
Bulk
Si la misma acción debe ejecutarse en varias tareas, puede ejecutarse como un 'conjunto' de tareas. En el HTM En este contexto, un bulk se refiere a una 'colección' de tareas. El bulk contiene una lista de identificadores de tareas y un conjunto de datos requeridos para un cierto tipo de acción.
Acciones soportadas
Las acciones masivas soportadas son:
Asigne y Ejecute Bulk Acción
Esta acción masiva combina dos acciones de tarea única separadas: Asignar y Ejecutar. Para cada taskId proporcionado en los datos de entrada, se realiza la acción de asignar tarea, luego para cada taskId se realiza la acción de ejecutar tarea.
Por ejemplo, si los datos de entrada contienen identificadores de tarea: [taskId1, taskId2], se realizarán las siguientes acciones de tarea única:
-
Tarea Asignar en tarea task Id1
-
Tarea Asignar en tarea task Id2
-
Tarea Ejecute la tarea task Id1
-
Tarea Ejecute la tarea task Id2
La activación de esta acción masiva se realiza a través de HTTP Solicitud POST /bulk-tasks/assign-and-execute. Para más detalles consulte API sección.
Además de validar los parámetros de solicitud requeridos, se implementan las siguientes validaciones:
-
Tamaño máximo de carga permitido - El número máximo de tareas en un lote es configurable a través de la propiedad ipf.htm.bulk.max-size y, por defecto, está establecido en 1000 tareas por lote. Si el lote contiene más tareas de las permitidas, se devolverá el siguiente error:
{
"code": "400",
"message": "Maximum bulk size exceeded",
"description": "Current bulk size 2000 exceeded maximum allowed bulk size 1000.",
"instance": "/bulk-tasks/assign-and-execute"
}
-
No se requieren aprobaciones - Solo se pueden procesar en bloque las tareas sin aprobaciones requeridas. Si al menos una de las tareas del bloque tiene aprobaciones requeridas > 0, el bloque no será procesado y se devolverá el siguiente error:
{
"code": "400",
"message": "Required approvals are not allowed for bulk task action",
"description": "Required approvals are not allowed for bulk task action, but the bulk contains 2 tasks with required approvals greater than 0.",
"instance": "/bulk-tasks/assign-and-execute"
}
-
Mismo tipo - Todas las tareas deben tener el mismo tipo. Si hay tareas con tipos diferentes, la mayoría no será procesada y se devolverá el siguiente error:
{
"code": "400",
"message": "All tasks from the bulk have to be of the same type",
"description": "All tasks from the bulk have to be of the same type, but this bulk has tasks of different types: [OTHER_PROCESSING, PAYMENT_PROCESSING].",
"instance": "/bulk-tasks/assign-and-execute"
}Obtener Bulk Informe de Acción
Esta acción devuelve información sobre el estado actual de la acción masiva. El cliente puede utilizar esta acción para verificar si la acción masiva aún está en procesamiento o si ha finalizado, comprobando si el estado es Processing o Completed.
La obtención del informe de acciones masivas se realiza a través de HTTP Solicitud GET /bulk-tasks/<bulk-id>. Para más detalles consulte API sección.
La información recuperada por el informe es:
-
createdAt: el momento en que se crea el lote (se inicia el procesamiento)
-
estado: estado actual de la acción masiva (Procesando o Completado)
-
operatorId: el id del operador que inició la acción masiva-taskIds: lista de identificadores de tareas incluidos en el lote-errores: lista de errores para una acción de tarea única. Se pueden realizar varias acciones de tarea única en una tarea. Por esta razón, la lista de errores puede contener múltiples errores para una sola tarea, pero cada error tiene información sobre la acción de tarea única.
"errors": [
{
"taskId": "b3f34207-992e-4e76-918d-e371c50861be",
"taskErrors": [
{
"action": "Allocate",
"error": "400: Invalid State - Invalid state 'Cancelled'. Current operation can only be performed from one of [Registered, Allocated] states."
},
{
"action": "Execute",
"error": "400: Invalid State - Invalid state 'Cancelled'. Current operation can only be performed from the 'Allocated' state."
}
]
}
]Implementación
La implementación se realiza utilizando un Akka Event Comportamiento Sourced (ESB) y un dedicado Event Procesador.
El agregado a granel se implementa como un estado triple. Event Comportamiento Sourced (ESB):
-
Listo
-
Procesamiento
-
Completado
Cuando se crea una nueva instancia de un ESB masivo, inicialmente se encuentra en el estado Listo, pero se cambia al estado Procesando de inmediato. Permanece en el estado Procesando hasta que se completan todas las acciones de tareas individuales. Luego, se cambia al estado Completado.
Diagrama de secuencia:
Cómo funciona la implementación de acciones de tareas en masa se explica aquí utilizando la acción en masa "Asignar y Ejecutar" como ejemplo.
Procesando Bulk Solicitud de Acción
Cuando se recibe una solicitud masiva de un cliente, se convierte en un comando, que luego se envía al agregado masivo. En este ejemplo, se recibe una solicitud de Asignar y Ejecutar con una lista de dos identificadores de tarea: tarea 1 y tarea 2. Se convierte en el comando Allocate And Execute Bulk y se envía al agregado masivo.
El agregado a granel produce los siguientes eventos:
-
ProcesamientoPorLotesIniciado-representa el inicio del procesamiento por lotes. El agregado por lotes reaccionará a este evento cambiando su estado a Procesando y almacenando todos los datos de entrada en el estado.
-
BulkProcessorTaskAllocate(tarea 1)- será procesado por el procesador de eventos en bloque, convirtiéndolo en un comando Task Allocate y enviándolo al agregado de Tareas.
-
BulkProcessorTaskAllocate(tarea 2)- lo mismo que para el evento anterior, solo para la tarea 2.
-
BulkProcessorTaskExecute(tarea 1)- será procesado por el procesador de eventos en masa, convirtiéndolo en un comando Task Execute y enviándolo al agregado de tareas.
-
BulkProcessorTaskExecute(tarea 2)- lo mismo que para el evento anterior, solo para la tarea 2.
-
BulkProcessorProcesamientoCompleto-será procesado por el procesador de eventos en bloque, enviando el comando Processing Bulk Done al agregado en bloque. El agregado en bloque reaccionará a este comando cambiando su estado a Completed.
EventsLos eventos con el prefijo de nombre Bulk Processor son procesados por el procesador de eventos en bloque, otros eventos son procesados por el agregado en bloque.
Los eventos Bulk Processor Task Allocate y Bulk Processor Task Execute son procesados por el procesador de eventos masivos, convirtiéndolos en comandos de Tarea individuales apropiados y enviando esos comandos al agregado de Tarea. Si ocurre un error durante una Acción de Tarea individual, el procesador recopilará información sobre el error y enviará el comando Processing Task Error al agregado masivo. El agregado masivo almacena el evento Bulk Task Processing Error y actualiza su estado con los detalles del error.
Al final, el procesador de eventos en bloque consume el último evento en bloque Bulk Processor Processing Done enviando el comando Processing Bulk Done al agregado en bloque. El agregado en bloque almacena un nuevo evento Bulk Processing Done y cambia su estado a Completed.
Este es el final del ciclo de vida del procesamiento por lotes.
Garantías
Bulkel almacenamiento agregado almacena ya sea todos los eventos o ninguno. Esta acción es atómica y está garantizada por Akka. Previene la situación en la que algunos eventos masivos son almacenados (y procesados por el procesador de eventos masivos) y otros no.
Si se produjo un error inesperado/sistema/tiempo de espera al enviar comandos para agregar en bloque desde el procesador de eventos en bloque, el evento (la fuente del comando) no se marcará como procesado (el desplazamiento del procesador de eventos en bloque no se actualizará). El Bulk el procesador de eventos intentará procesar el mismo evento nuevamente.
Bulkel procesador de eventos envía comandos al agregado masivo utilizando Akka patrón de consulta. Es posible que el agregado masivo reciba un comando y, como resultado del procesamiento del comando, devuelva una respuesta de fallo. Ante una respuesta de fallo, el procesador de eventos masivos registra el error y continúa. En el caso de un error que es manejado por el agregado masivo, el procesamiento masivo no se detiene (el procesamiento de eventos no se reintentará).