WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Tratando Erros em Fluxos de Mensagens

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.

Há duas abordagens gerais para manipular erros em um fluxo de mensagens:
  • Falha na verificaçã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.

  • Capturando exceções

    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:

Os princípios gerais de tratamento de erro são:
  • Se você conectar o terminal Catch do nó de entrada, estará indicando que o fluxo trata todas as exceções que são geradas em qualquer lugar no fluxo de saída. O broker não executa nenhum retrocesso e não executa nenhuma ação, a menos que haja uma exceção no fluxo de captura. Se você deseja alguma ação rollback depois que uma exceção for levantada e capturada, será necessário fornecê-la no fluxo catch.
  • Se você não conectar o terminal Catch do nó de entrada, poderá conectar o terminal Failure e fornecer um fluxo de falhas para manipular exceções geradas pelo nó. O fluxo de falhas é iniciado automaticamente quando ocorre uma exceção no nó.

    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.

  • Se um nó propagar uma mensagem para um fluxo de captura, e ocorrer outra exceção que retorne o controle ao mesmo nó novamente, o nó manipulará a mensagem como se o terminal Catch não estivesse conectado.
  • Se você não conectar os terminais Failure ou Catch do nó de entrada, o broker fornecerá o processamento padrão (que varia com o tipo de nó de entrada).
  • Se precisar de uma abordagem de erro e de recuperação mais abrangente, inclua um ou mais nós TryCatch para fornecer áreas localizadas de manipulação de erros.
  • Se você possui um procedimento comum para tratamento de erros específicos, talvez seja apropriado criar um subfluxo que inclua a seqüência de nós necessários. Inclua esse subfluxo sempre que precisar que essa medida seja tomada.

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.

A amostra a seguir demonstra como utilizar uma rotina de manipulação de erros para capturar informações sobre erros e armazenar essas informações em um banco de dados. A rotina de tratamento de erros é um subfluxo que pode ser incluído, inalterado, em seus fluxos de mensagens. A amostra também demonstra como configurar os fluxos de mensagens para controlar a transacionalidade; principalmente, a utilização de transações coordenadas globalmente para assegurar integridade geral dos dados.

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.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:12


Tópico de TarefaTópico de Tarefa | Versão 8.0.0.5 | ac00410_