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, 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.
Você pode
escolher uma ou mais dessas opções em seu fluxo de mensagens:
- Conecte o terminal Failure de qualquer nó a uma sequência de nós que processa a exceção interna do nó (o
fluxo de falhas).
- Conecte o terminal Catch do nó de entrada ou um nó
TryCatch a uma sequência de nós que processa as exceções
geradas além (do fluxo de captura).
- Insira um ou mais nós TryCatch em pontos
específicos no fluxo de mensagens para capturar e processar exceções que são geradas pelo fluxo conectado ao
terminal Try.
- Inclua um nó Throw ou codifique
uma instrução ESQL THROW para gerar uma exceção.
- Conecte o terminal Catch do nó AggregateReply
para processar exceções de agregação, se estiver utilizando agregação.
- Certifique-se de que todas as mensagens recebidas por um nó MQInput
sejam processadas em uma transação ou não sejam processadas em uma transação.
- Certifique-se de que todas as mensagens recebidas por um nó MQInput
sejam persistentes ou não sejam persistentes.
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:
- A maioria dos nós integrados possuem terminais Failure. As exceções são os
nós AggregateControl, AggregateRequest, Entrada, Label, Saída, Passthrough, Publicação, Real-timeInput Real-timeOptimizedFlow, Throw, Trace
e TryCatch.
Quando é detectada uma exceção em um nó, as
informações da mensagem e da exceção são propagadas para o terminal Failure do nó. Se o nó não tiver um
terminal Failure, ou se não estiver conectado, o intermediário emitirá uma exceção e retornará o controle ao
nó anterior mais próximo que possa processá-lo. Este pode ser um nó TryCatch,
um nó AggregateReply ou o nó input.
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 intermediário.
Para obter informações adicionais, consulte o Manipulando Erros de MQInput.
- Um pequeno número de nós integrados possui terminais Catch. Estes são os nós
AggregateReply,
HTTPInput, MQInput,
SCADAInput, JMSInput,
JMSOutput,
TimeoutNotification e
TryCatch.
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).
- Quando uma mensagem é propagada para o terminal Failure ou Catch, o nó cria e preenche uma nova
ExceptionList com uma exceção que representa o erro ocorrido. ExceptionList é propagado como parte da árvore de
mensagens.
- O nó MQInput e o nós TimeoutNotification possuem processamento adicional para mensagens transacionais (outros nós input não manipulam
mensagens transacionais).
Para obter informações adicionais, consulte o Manipulando Erros de MQInput e o Manipulando Erros de TimeoutNotification.
- Se você incluir um nó Trace
que especifica $Root ou $Body, a mensagem
completa será analisada. Isso pode gerar erros no analisador não detectados de outra forma.
Os princípios gerais de tratamento de erro são:
- Se você conectar o terminal de Catch do nó de entrada, estará indicando que o fluxo manipula todas as
exceções geradas em qualquer lugar no fluxo de saída. O intermediário não executa nenhum
rollback e não toma nenhuma medida, a menos que exista uma exceção no
fluxo catch. 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ó MQInput
ou HTTPInput, 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.
Os nós HTTPInput e
SCADAInput não propagarão a mensagem para o terminal Failure se
for gerada uma exceção além do nó e você não tiver conectado 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 intermediário 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:
- Você pode especificar se as atualizações estão consolidadas ou
revertidas. É possível configurar a
propriedade do nó Transação para
especificar se as atualizações de banco de dados estão confirmadas ou recuperadas com o
fluxo de mensagens (opção Automático) ou
confirmadas ou recuperadas quando o próprio nó for encerrado (opção Confirmar). Você
deve assegurar-se de que a combinação dessas definições de
propriedades e o processamento de erros do fluxo de mensagens gerem o
resultado correto.
- Você pode especificar como os erros do banco de dados são
manipulados. Você pode definir as propriedades
Tratar Avisos como
Erros e Emitir
Exceção sobre Erro no Banco de Dados para alterar o
comportamento padrão de tratamento de erros do banco de dados.
Para obter informações adicionais sobre as
atualizações de banco de dados coordenadas, consulte
Configurando Fluxos de Mensagens Coordenados Globalmente.
Os fluxos de mensagens para agregação envolvem considerações adicionais que não serão discutidas 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 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.
Você
pode visualizar amostras apenas quando utilizar o centro de informações integrado
ao Message
Brokers Toolkit.