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:
- Conecte o terminal failure de qualquer nó a uma seqüência de nós
que processa a exceção interna do nó (o fluxo com falha).
- Conecte o terminal catch do nó de entrada ou um
nó TryCatch a uma seqüência de nós que processa 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 as exceções geradas
pelo fluxo conectado ao terminal try.
- Inclua um nó Throw ou codifique uma instrução ESQL
THROW para gerar uma exceção.
- Se você estiver utilizando a agregação, conecte o
terminal catch do nó AggregateReply para processar exceções de
agregação.
- Assegure que todas as mensagens recebidas por um nó MQInput sejam processadas em uma transação ou não.
- Assegure que todas as mensagens recebidas por um nó MQInput sejam persistentes ou não.
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:
- A maioria dos nós internos possuem terminais failure. As exceções
são AggregateControl. AggregateRequest, Input,
Label, Output, Passthrough, Publication,
Real-timeInput, Real-timeOptimizedFlow,
Throw, Trace e TryCatch.
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.
Para obter informações adicionais, consulte o seguinte:
- Um pequeno número de nós internos possui
terminais catch.
São eles: AggregateReply, HTTPInput, MQInput,
SCADAInput, JMSInput, JMSOutput, TimeoutNotification e TryCatch.
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).
- Quando uma mensagem é propagada para o terminal de falha ou de
captura, o nó cria e ocupa uma nova ExceptionList com uma exceção que
representa o erro ocorrido. ExceptionList é propagado como parte da árvore de
mensagens.
- Nós MQInput
e TimeoutNotification têm processamento adicional para mensagens transacionais (outros nós de entrada não manipulam mensagens transacionais).
Para obter informações adicionais, consulte os seguintes tópicos:
- 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 catch do nó de entrada, estará
indicando que o fluxo manipula todas as exceções geradas em qualquer
local 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 as exceções
geradas pelo nó.
O fluxo fail é chamado imediatamente quando ocorre uma exceção no nó.
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.
- Se um nó propagar uma mensagem para um fluxo de captura e ocorrer
outra exceção que devolva o controle para o mesmo nó novamente, o nó
manipulará a mensagem como se o terminal de captura 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 você precisar de um erro mais abrangente e de uma
abordagem de recuperação, inclua um ou mais nós TryCatch para
fornecer áreas mais localizadas de tratamento 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 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:
- Você pode especificar se as atualizações estão consolidadas ou
revertidas. Você pode definir a propriedade de nó
Transaction para
especificar se as atualizações de banco de dados estão consolidadas
ou revertidas com o fluxo de mensagens (opção
Automatic) ou
consolidadas ou revertidas quando o próprio nó termina (opção
Commit). 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 Transações do Fluxo de Mensagens.
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.