Fila de Mensagens Mortas para Jitterbit Message Queue

Visão Geral

Esta página descreve como implementar um padrão de design de Fila de Mensagens Mortas (DLQ) usando o Serviço de Fila de Mensagens Jitterbit e o conector Jitterbit MQ.

Um padrão DLQ roteia mensagens que não podem ser processadas com sucesso através de uma série de filas de tentativa com atrasos crescentes antes de colocá-las em uma DLQ final para inspeção manual.

Limitações de NACK e reprocessamento

Um padrão comum de integração é usar a atividade NACK com a opção Reprocessar Mensagens Após NACK para retornar uma mensagem à fila quando o processamento falha. Por exemplo, uma integração de faturamento de pedidos pode consultar um sistema ERP repetidamente até que um pedido atinja o status esperado.

Essa abordagem tem duas desvantagens significativas quando usada com filas Quorum:

• Mensagens que não podem ser processadas imediatamente são retornadas ao início da fila e tentadas continuamente, consumindo recursos de processamento.
• Filas Quorum impõem um limite de entrega de 20 tentativas. Após uma mensagem ser negativamente reconhecida 20 vezes, ela é removida permanentemente da fila sem uma mensagem de erro.

O padrão DLQ usa a atividade NACK com a opção Rejeitar Mensagens Após NACK em vez disso, e implementa um roteamento explícito para um conjunto de filas de tentativa com atrasos crescentes, conforme descrito nas seções a seguir.

Visão Geral do Padrão

O padrão DLQ utiliza múltiplas filas e um conjunto de operações do Studio:

1. Mensagens são processadas a partir de uma fila principal.
2. Em caso de falha, a mensagem é rejeitada (não reprocessada) e enviada para a primeira fila de tentativa com um valor retryCount incrementado na carga útil.
3. Uma operação agendada lê de cada fila de tentativa após seu intervalo de atraso e encaminha mensagens de volta para a fila principal para reprocessamento.
4. Após um número máximo de tentativas configurável, as mensagens são enviadas para a DLQ para inspeção manual.

Configuração da fila

Crie as cinco filas a seguir na página Filas de mensagens do Console de Gerenciamento. Todas as filas devem usar o tipo Quorum para durabilidade.

Requisitos do payload da mensagem

Para rastrear tentativas de processamento com falha, adicione um campo retryCount (um inteiro começando em 0) ao seu payload de mensagem. Em cada tentativa de processamento com falha, configure a operação do processador principal para realizar os seguintes passos:

1. Leia retryCount do campo messageBody no esquema de resposta da Obter atividade.

2. Incremente o valor usando um script ou transformação.

3. Escreva o valor atualizado de volta pelo campo messageBody no esquema de solicitação da Enviar atividade ao direcionar para a fila de tentativas.

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

Design do fluxo de trabalho

Operação do processador principal

Configure esta operação para ler de orders.main e tentar processar cada mensagem.

1. Use a Atividade de Obtenção para recuperar uma mensagem de orders.main.

2. Tente processar a mensagem (por exemplo, consulte o sistema ERP para o status esperado do pedido).

3. Use ações da operação para configurar as seguintes ações:

   • Em Caso de Sucesso: Execute uma operação que utilize a Atividade de Reconhecimento para reconhecer a mensagem.

   • Em Caso de Falha: Execute uma operação que realize os seguintes passos:

     1. Leia retryCount da carga útil da mensagem e incremente em 1.

     2. Use a Atividade de Envio para enviar a mensagem atualizada para a fila de retry apropriada:

        Valor de retryCount	Fila de Destino
        1	orders.retry.1m
        2	orders.retry.5m
        3 ou 4	orders.retry.30m
        Maior que 4	orders.dlq

     3. Use a Atividade NACK com Rejeitar Mensagens Após NACK para remover a mensagem de orders.main.

Operações do encaminhador de retry

Crie uma operação de encaminhador para cada fila de retry. Configure cada operação para ler mensagens de sua fila de retry, enviá-las de volta para orders.main para reprocessamento e executar em um cronograma que corresponda ao atraso pretendido:

Configure cada operação para seguir estas etapas:

1. Use a Atividade de obter para recuperar uma mensagem da fila de retry.

2. Use a Atividade de enviar para enviar a mensagem para orders.main, preservando o valor de retryCount no payload.

3. Use a Atividade de reconhecer para reconhecer a mensagem da fila de retry.

Operação do inspetor de DLQ (opcional)

Crie uma operação que leia de orders.dlq para alertar ou registrar mensagens que esgotaram todas as tentativas de retry. Esta operação pode enviar notificações por email, escrever em um log ou acionar um fluxo de trabalho de revisão manual.