O intermediário 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 determinados erros a serem processados de uma maneira específica ou um fluxo que atualiza um banco de dados e precisa reverter 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, pois esses nós lidam com mensagens e transações persistentes. As opções de configuração para WebSphere MQ também afetam o MQInput.
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.
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, é necessário consultar as informações fornecidas com o nó para entender como você pode manipular os erros desses 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 dentro de um nó, a mensagem e as informações de exceção são propagadas para o terminal failure do nó. Se o nó não possuir um terminal failure ou não estiver conectado, o intermediário emitirá uma exceção e retornará o controle ao nó anterior mais próximo do que pode processá-lo. Pode ser um nó TryCatch, um nó AggregateReply ou um nó de entrada.
Se um nó MQinput detectar um erro interno, seu comportamento será levemente diferente; se o terminal de falha não estiver conectado, ele tentará colocar a mensagem na fila de novo enfileiramento de backout da fila de entrada ou (se não estiver definida) na fila de devoluções do gerenciador de filas do intermediário.
Uma mensagem é propagada em um terminal catch apenas se tiver sido propagada primeiro além do nó (por exemplo, para os nós conectados ao terminal de saída).
Os princípios gerais de tratamento de erro são:
O fluxo de falha também é chamado se uma exceção for gerada além do nó MQInput (em fluxos de saída ou de captura), a mensagem é transacional e a restauração da mensagem na fila de entrada faz com que a contagem de backout atinja o limite de backout.
Os nós HTTPInput e SCADAInput não propagarão a mensagem para o terminal failure, se uma exceção for gerada além do nó e não tiver conectado o terminal catch.
Para obter informações adicionais, consulte os seguintes tópicos:
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 Nós para Fluxos de Mensagens Coordenados.
Os fluxos de mensagens para agregação envolvem considerações adicionais que não são discutidas nessa seção; elas estão descritas em Manipulação de Exceções em Fluxos de Agregação.
O Amostra Error Handler demonstra como utilizar uma rotina de manipulação de erro para captar informações sobre erros e armazenar essas informações em um banco de dados. A rotina de manipulação de erro é um subfluxo que você pode incluir, inalterado, em qualquer fluxo 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.