O broker fornece tratamento de erro básico para todos os fluxos de mensagens. Se o processamento básico não for suficiente e você deseja tomar medidas específicas em resposta a determinadas condições e situações de erro, será possível aprimorar seus fluxos de mensagens para fornecer seu próprio tratamento de erros.
Por exemplo, você pode projetar um fluxo de mensagens que espera alguns erros a serem processados de uma maneira específica. Ou talvez seu fluxo atualize um banco de dados e deva retroceder essas atualizações, se outro processamento não for concluído com êxito.
As opções que você pode utilizar para isso são um tanto complexas em alguns casos. As opções fornecidas para os nós MQInput e TimeoutNotification são extensivas, porque estes nós lidam com mensagens e transações persistentes. O nó MQInput também é afetado por opções de configuração para o WebSphere MQ.
Como você pode decidir manipular diferentes erros de diferentes maneiras, não há procedimentos pré-determinados a serem descritos. Esta seção fornece informações sobre princípios de manipulação de erros e as opções disponíveis e você deve decidir qual combinação de opções é necessária em cada situação, com base nos detalhes fornecidos nesta seção.
Ligue o terminal de Falha de um nó para verificar explicitamente quaisquer erros que ocorram nesse nó. Se ocorrerem erros, uma lista de exceções será propagada para o terminal de Falha. A mensagem em andamento permanece igual a de antes de o nó ser chamado.
É possível introduzir uma verificação de erros mais especializada em nós que podem ser customizados usando ESQL. Por exemplo, é possível criar manipuladores de saída nesses nós. Para obter informações adicionais sobre o uso de ESQL para criar manipuladores de saída, consulte Instrução DECLARE HANDLER.
Se você não ligar um terminal de Falha, uma falha no nó será convertida em uma exceção que será lançada a partir do nó. Quaisquer alterações feitas na mensagem em andamento antes de a exceção ser lançada serão revertidas. A exceção pode fazer com que a transação atual seja retrocedida, o que significa que quaisquer atualizações nos recursos transacionais serão revertidas.
É possível evitar que a transação seja retrocedida e controlar a extensão na qual as alterações na mensagem são revertidas, incluindo um nó TryCatch em seu fluxo de mensagens. Se uma exceção for lançada além do terminal de Tentativa do nó TryCatch, então uma lista de exceções será propagada para o terminal de Captura do nó. A mensagem em andamento será revertida para o estado em que estava antes de ela atingir o nó TryCatch.
Outros nós separados do nó TryCatch possuem um terminal de Captura. Esses nós estão geralmente no início de uma transação, em que uma exceção não capturada causaria um retrocesso. Nesses nós, o terminal de Captura se comporta como se um nó TryCatch estivesse ligado diretamente ao terminal de Saída. Use o terminal de Captura para manipular quaisquer exceções lançadas além do nó no fluxo de mensagens. Ligue o terminal de Falha para manipular erros no próprio nó.
Você pode escolher uma ou mais dessas opções em seu fluxo de mensagens:
Se você incluir nós definidos pelo usuário em seu fluxo de mensagens, deverá ver as informações fornecidas com o nó para entender como você pode manipular erros com estes nós. As descrições desta seção abrangem apenas os nós internos.
Ao projetar sua abordagem de manipulação de erros, considere os seguintes fatores:
Quando uma exceção é detectada em um nó, a mensagem e as informações de exceção são propagadas para o terminal de Falha do nó. Se o nó não tiver um terminal Failure, ou se ele não estiver conectado, o broker lançará uma exceção e retornará o controle ao nó de envio de dados mais próximo que pode processá-lo. Este nó pode ser um nó TryCatch, um nó AggregateReply ou o nó de entrada.
Se um nó MQInput detectar um erro interno, seu comportamento será um pouco diferente; se o terminal Failure não estiver conectado, ele tentará colocar a mensagem na fila de novo enfileiramento de restauração da fila de entrada, ou (se não estiver definida) na fila de devoluções do gerenciador de filas do broker.
Para obter informações adicionais, consulte o Manipulando Erros de Entrada MQ.
Uma mensagem será propagada para um terminal Catch apenas se primeiro tiver sido propagada além do nó (por exemplo, para os nós conectados ao terminal Out).
Para obter informações adicionais, consulte o Manipulando Erros de Entrada MQ e o Tratando de Erros de Notificação de Tempo Limite.
O fluxo de falhas também será iniciado se for gerada uma exceção além do nó MQInput (nos fluxos de saída ou de captura), se a mensagem for transacional e o restabelecimento da mensagem na fila de entrada fizer a contagem de restaurações atingir o limite de restauração.
O nó HTTPInput não propaga a mensagem para o terminal Failure se uma exceção for gerada além do nó e você não conectou o terminal Catch.
Para obter informações adicionais, consulte Conectando Terminais com Falha, Gerenciando Erros no Nó Input e Capturando Exceções em um Nó TryCatch.
Se seu fluxo de mensagens incluir atualizações de banco de dados, a maneira na qual você configura os nós que interagem com esses bancos de dados também pode afetar a maneira como esses erros são manipulados:
Para obter informações adicionais sobre as atualizações de banco de dados coordenadas, consulte Configurando a Transacionalidade para os Fluxos de Mensagens.
Os fluxos de mensagens para agregação envolvem fatores adicionais que não são discutidos neste tópico. Para obter informações adicionais sobre fluxos de mensagens para agregação, consulte Manipulando Exceções em Fluxos de Agregação.
Você só pode visualizar informações sobre amostras quando usa o centro de informações que está integrado ao WebSphere Message Broker Toolkit ou o centro de informações on-line. Você só poderá executar amostras quando usar o centro de informações que está integrado ao WebSphere Message Broker Toolkit.