O nó MQInput toma determinadas ações ao manipular erros com mensagens persistentes e transacionais. O nó tenta o processamento da repetição quando uma mensagem transacional é retrocedida para a fila de entrada. As mensagens não transacionais não são retrocedidas para a fila de entrada quando ocorre uma exceção.
Os erros encontrados com mensagens não transacionais são manipulados conforme descrito em Gerenciando Erros no Nó Input.
Esta ação é resumida na tabela a seguir.
Evento de Erro | Terminal Failure Conectado | Terminal Failure Não Conectado | Terminal Catch Conectado | Terminal Catch Não Conectado |
---|---|---|---|---|
O nó detecta erro interno | Fluxo conectado ao terminal de Falha manipula o erro | Mensagem colocada na fila alternativa; novas tentativas de nó se a colocação falhar | Não se aplica | Não se aplica |
O nó propaga mensagem para terminal failure, ocorre exceção no fluxo de saída | Não se aplica | Não se aplica | Fluxo conectado ao terminal Catch manipula o erro | Novas tentativas para nós |
O nó propaga a mensagem para o terminal Catch, ocorre uma exceção no fluxo conectado ao terminal Catch | Erro registrado, mensagem revertida | Erro registrado, mensagem revertida | Não se aplica | Não se aplica |
O nó propaga a mensagem para o terminal de Falha, ocorre uma exceção no fluxo conectado ao terminal de Falha | Não se aplica | Não se aplica | Novas tentativas para nós | Novas tentativas para nós |
O nó tenta o processamento de nova tentativa quando uma mensagem é revertida para a fila de entrada. Ele verifica se a mensagem foi restaurada anteriormente e, se tiver sido, se a contagem de restauração foi alcançada (igualada) ao limite de restauração. A contagem de recuperação para cada mensagem é mantida pelo WebSphere MQ no MQMD.
Você especifica o atributo de limite de restauração BOTHRESH (ou permite que seja padronizado com 0) ao criar a fila. Se você aceitar o valor padrão 0, o nó aumentará esse valor para 1. O nó também configurará o valor como 1 se não puder detectar o valor atual. Se o limite de restauração estiver configurado como 1, a mensagem será processada uma vez, mas não será recuperada por meio do terminal de Saída do nó MQInput. Para tentar novamente a mensagem pelo menos uma vez, configure o limite de restauração como 2.
Se ocorrer uma falha além do terminal de Falha, serão feitas novas tentativas adicionais até que o campo de contagem de backout no MQMD alcance o dobro do limite de backout configurado para a fila de entrada. Quando esse limite for alcançado, o nó tentará colocar a mensagem em outra fila.
A mensagem não pode ser descartada, portanto, o fluxo de mensagens continuará tentando recuperar a mensagem. Ele registra a situação de erro gravando erros no registro de erros local. A segunda indicação desse erro é o incremento contínuo de BackoutCount da mensagem na fila de entrada.
Se essa situação tiver ocorrido porque não existe fila, você poderá definir uma das filas de recuperação mencionadas acima. Se a condição que impede que a mensagem seja processada for corrigida, será possível aumentar temporariamente o valor do atributo BOTHRESH. Isto força a mensagem através do processamento normal.
WebSphere MQ suporta grupos de mensagens. Você pode especificar que uma mensagem pertence a um grupo e seu processamento é então concluído com referência a outras mensagens no grupo (ou seja, todas as mensagens são consolidadas ou todas as mensagens são revertidas). Ao enviar mensagens agrupadas a um intermediário, essa condição será sustentada se você tiver configurado o fluxo de mensagens corretamente e os erros não ocorrerem durante o processamento da mensagem do grupo.
Para configurar o fluxo de mensagens para tratar corretamente de mensagens agrupadas, siga as ações descritas no Nó MQInput. No entanto, o processamento correto do grupo de mensagens não poderá ser garantido se ocorrer um erro enquanto uma das mensagens estiver sendo processada.
Se você tiver configurado o nó MQInput, conforme descrito, sob circunstâncias normais todas as mensagens do grupo serão processadas em uma única unidade de trabalho que será consolidada quando a última mensagem do grupo tiver sido processada com êxito. No entanto, se ocorrer um erro antes do processamento da última mensagem no grupo, a unidade de trabalho que inclui as mensagens e incluindo a mensagem que gerou o erro estará sujeita ao tratamento de erros definido pelas regras documentadas aqui, o que pode resultar na recuperação da unidade de trabalho.
Entretanto, todas as mensagens restantes no grupo podem ser lidas e processadas, com êxito, pelo fluxo de mensagens, e, portanto, são manipuladas e consolidadas em uma nova unidade de trabalho. Será emitida uma consolidação quando a última mensagem for encontrada e processada. Assim, se ocorrer um erro em um grupo, mas não na primeira ou na última mensagem, é possível que parte do grupo seja retornado e outra parte consolidada.
Se os requisitos de processamento da mensagem exigirem que essa situação seja tratada de uma maneira particular, você deverá fornecer manipulação de erros adicional para manipular erros em grupos de mensagens. Por exemplo, é possível registrar a falha do grupo de mensagens em um banco de dados e incluir uma verificação no banco de dados quando recuperar cada mensagem, forçando um retrocesso se o grupo atual já tiver encontrado um erro. Isto assegura que todo o grupo de mensagens será recuperado e não processado, a menos que todas as mensagens sejam bem-sucedidas.