Cola de Mensajes Muertos para Jitterbit Message Queue

Descripción General

Esta página describe cómo implementar un patrón de diseño de Cola de Mensajes Muertos (DLQ) utilizando el Servicio de Cola de Mensajes de Jitterbit y el conector Jitterbit MQ.

Un patrón DLQ enruta mensajes que no pueden ser procesados con éxito a través de una serie de colas de reintento con retrasos crecientes antes de colocarlos en una DLQ final para inspección manual.

Limitaciones de NACK y reintento

Un patrón de integración común es utilizar la actividad NACK con la opción Reintentar Mensajes Después de NACK para devolver un mensaje a la cola cuando el procesamiento falla. Por ejemplo, una integración de facturación de pedidos puede consultar un sistema ERP repetidamente hasta que un pedido alcance el estado esperado.

Este enfoque tiene dos desventajas significativas cuando se utiliza con colas de Quorum:

• Los mensajes que no pueden ser procesados de inmediato se devuelven a la cabeza de la cola y se reintentan continuamente, consumiendo recursos de procesamiento.
• Las colas de Quorum imponen un límite de entrega de 20 intentos. Después de que un mensaje ha sido reconocido negativamente 20 veces, se elimina permanentemente de la cola sin un mensaje de error.

El patrón DLQ utiliza la actividad NACK con la opción Rechazar Mensajes Después de NACK en su lugar, e implementa un enrutamiento explícito a un conjunto de colas de reintento con retrasos escalonados, como se describe en las siguientes secciones.

Descripción del Patrón

El patrón DLQ utiliza múltiples colas y un conjunto de operaciones de Studio:

1. Los mensajes se procesan desde una cola principal.
2. En caso de fallo, el mensaje se rechaza (no se reintenta) y se envía a la primera cola de reintento con un valor de retryCount incrementado en la carga útil.
3. Una operación programada lee de cada cola de reintento después de su intervalo de retraso y reenvía los mensajes de vuelta a la cola principal para reprocesamiento.
4. Después de un número máximo de intentos configurable, los mensajes se envían a la DLQ para inspección manual.

Configuración de la cola

Cree las siguientes cinco colas en la página Colas de mensajes de la Consola de Administración. Todas las colas deben utilizar el tipo Quorum para durabilidad.

Requisitos del payload del mensaje

Para rastrear los intentos de procesamiento fallidos, agregue un campo retryCount (un entero que comienza en 0) a su payload de mensaje. En cada intento de procesamiento fallido, configure la operación del procesador principal para realizar los siguientes pasos:

1. Lea retryCount del campo messageBody en el esquema de respuesta de Obtener actividad.

2. Incremente el valor utilizando un script o transformación.

3. Escriba el valor actualizado de nuevo a través del campo messageBody en el esquema de solicitud de Enviar actividad al enrutar a la cola de reintento.

{
"orderId": "ORD-12345",
"retryCount": 0
}

Diseño del flujo de trabajo

Operación del procesador principal

Configura esta operación para leer de orders.main e intentar procesar cada mensaje.

1. Usa la Actividad de Obtener para recuperar un mensaje de orders.main.

2. Intenta procesar el mensaje (por ejemplo, consulta el sistema ERP para el estado esperado del pedido).

3. Usa acciones de operación para configurar las siguientes acciones:

   • En Éxito: Ejecuta una operación que utilice la Actividad de Reconocimiento para reconocer el mensaje.

   • En Fallo: Ejecuta una operación que realice los siguientes pasos:

     1. Lee retryCount del payload del mensaje e incrementa su valor en 1.

     2. Usa la Actividad de Enviar para enviar el mensaje actualizado a la cola de reintentos apropiada:

        Valor de retryCount	Cola de destino
        1	orders.retry.1m
        2	orders.retry.5m
        3 o 4	orders.retry.30m
        Mayor que 4	orders.dlq

     3. Usa la Actividad de NACK con Rechazar Mensajes Después de NACK para eliminar el mensaje de orders.main.

Retry forwarder operations

Cree una operación de reenvío para cada cola de reintento. Configure cada operación para leer mensajes de su cola de reintento, enviarlos de vuelta a orders.main para reprocesamiento y ejecutarse en un horario que coincida con el retraso previsto:

Configure cada operación para seguir estos pasos:

1. Use la Actividad de obtener para recuperar un mensaje de la cola de reintento.

2. Use la Actividad de enviar para enviar el mensaje a orders.main, preservando el valor de retryCount en la carga útil.

3. Use la Actividad de reconocer para reconocer el mensaje de la cola de reintento.

DLQ inspector operation (optional)

Cree una operación que lea de orders.dlq para alertar o registrar mensajes que han agotado todos los intentos de reintento. Esta operación puede enviar notificaciones por correo electrónico, escribir en un registro o activar un flujo de trabajo de revisión manual.