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

Codificando o ESQL para Tratar Erros

Ao processar mensagens em um fluxo de mensagens, os erros podem ter várias causas diferentes e o designer do fluxo de mensagens deve decidir como manipular estes erros.

Introdução

Ao processar mensagens em fluxos de mensagens, os erros podem ter as seguintes causas:
  • Causas externas; por exemplo, a mensagem que chega é sintaticamente inválida, um banco de dados utilizado pelo fluxo foi encerrado ou a fonte de alimentação para a máquina na qual o intermediário está em execução falhou.
  • Causas internas; por exemplo, uma tentativa de inserir uma linha em uma tabela de banco de dados falha devido a uma verificação de restrição ou uma cadeia de caracteres lida de um banco de dados não pode ser convertida em um número, porque contém caracteres alfabéticos.

    Os erros internos podem ser causados por programas que armazenam dados inválidos no banco de dados ou por uma falha na lógica de um fluxo.

O designer do fluxo de mensagens deve decidir como manipular erros.

Utilizando a Identificação de Erros Padrão

A estratégia mais simples para manipular erros de ESQL é não fazer nada e usar o comportamento padrão do intermediário. O comportamento padrão é reduzir o processamento da mensagem com falha e continuar com a próxima mensagem. Os nós de entrada e de saída fornecem opções para controlar exatamente o que acontece quando o processamento é interrompido.

Se os nós de entrada e saída forem configurados para o modo transacional, o intermediário restaurará o estado antes da mensagem ser processada:
  1. A mensagem de entrada que aparentemente foi obtida da fila de entrada é retornada.
  2. As mensagens de saída que o fluxo aparentemente gravou nas filas de saída são descartadas.
Se os nós de entrada e de saída não estiverem configurados para o modo transacional:
  1. A mensagem de entrada que foi obtida da fila de entrada não é retornada.
  2. Todas as mensagens de saída que o fluxo gravou nas filas de saída permanecem nas filas de saída.

Cada uma destas estratégias tem suas vantagens. O modelo transacional preserva a consistência de dados, enquanto o modelo não transacional aumenta a continuidade do processamento de mensagens. No modelo transacional, a mensagem de entrada com falha é retornada à fila de entrada e o intermediário tenta processá-la novamente. O resultado mais provável desse cenário é que a mensagem continuará falhando até que seja alcançado o limite de nova tentativa e, nesse ponto, ela é colocada em uma fila de devoluções. A razão para a falha ao processar a mensagem é registrada no log de eventos do sistema (Windows) ou no syslog (UNIX). Portanto, a mensagem com falha suspende o processamento de mensagens válidas subseqüentes e permanece não processada pelo intermediário.

A maioria dos bancos de dados opera de forma transacional; por isso, todas as alterações feitas em tabelas de banco de dados serão confirmadas se o processamento da mensagem for bem-sucedido e revertidas se ele falhar, mantendo, assim, a integridade de dados. Uma exceção a essa situação ocorre quando o próprio intermediário, ou um banco de dados, falha (por exemplo, a energia para os computadores nos quais eles estão em execução é interrompida). Nesses casos, as alterações poderão ser confirmadas em alguns bancos de dados, mas não em outros, ou as alterações do banco de dados poderão ser confirmadas, mas as mensagens de entrada e saída não são confirmadas. Se estas possibilidades forem preocupantes, torne o fluxo coordenado e configure os bancos de dados envolvidos.

Utilizando a Manipulação de Erro Customizada

A lista a seguir contém algumas dicas gerais para criar manipuladores de erro customizados.
  • Se precisar de algo melhor do que a manipulação de erros padrão, a primeira etapa será utilizar um manipulador; consulte Instrução DECLARE HANDLER. Crie um manipulador por nó para interceptar todas as exceções possíveis (ou todas aquelas que você pode prever).
  • Tendo interceptado um erro, a rotina de tratamento de erros pode utilizar qualquer lógica apropriada para tratá-lo. Como alternativa, ela pode utilizar uma instrução THROW ou um nó para criar uma exceção, que poderá ser manipulada de forma superior na lógica de fluxo ou mesmo alcançar o nó de entrada, causando a reversão da transação; consulte Lançando uma Exceção.
  • Se um nó gerar uma exceção não capturada pelo manipulador, o fluxo será desviado para o terminal Failure, se um estiver conectado, ou manipulado pela manipulação de erros padrão se nenhum terminal Failure estiver conectado.

    Utilize os terminais de falha para capturar erros não manipulados. Conecte um fluxo de lógica simples ao terminal de falha. Este fluxo lógica pode consistir em um banco de dados ou nó Compute que grava um registro de log em um banco de dados (possivelmente incluindo o fluxo de bits da mensagem) oy grava um registro no log de eventos. O fluxo também pode conter um nó de saída que grava a mensagem em uma fila especial.

    A árvore de exceções completa é transmitida a qualquer nó conectado a um terminal de falha; consulte Estrutura em Árvore da Lista de Exceções.

  • Suas rotinas de tratamento de erros são responsáveis por registrar cada erro em um local apropriado, como o registro de eventos do sistema.

Para obter uma descrição detalhada das opções que você pode utilizar para processar erros em um fluxo de mensagens, consulte Tratando Erros em Fluxos de Mensagens. Para obter exemplos do que pode ser feito, consulte Lançando uma Exceção e Capturando o Estado do Banco de Dados.

Gravando Código para Detectar Erros

As seções a seguir assumem que o intermediário detecta o erro. Entretanto, é possível que a lógica do fluxo detecte um erro. Por exemplo, ao codificar a lógica do fluxo, você poderá utilizar os seguintes elementos:
  • Instruções IF inseridas especificamente para detectar situações que não devem ocorrer
  • A cláusula ELSE de uma expressão ou instrução case para interromper rotas por meio do código que não deve ser possível
Como exemplo de um erro detectado por uma lógica de fluxo, considere um campo que tenha um intervalo de possíveis valores inteiros que indicam o tipo de mensagem. Não seria recomendável esperar para ver o que aconteceria se chegasse uma mensagem na qual o valor do campo não correspondesse a nenhum tipo de mensagem conhecido. Uma maneira de isso ocorrer é quando o sistema é atualizado para suportar tipos adicionais de mensagem, mas uma parte do sistema não é atualizada.

Utilizando sua Própria Lógica para Manipular Mensagens de Entrada Inválidas

As mensagens de entrada que são sintaticamente inválidas (e as mensagens de entrada que parecem não ser válidas devido a informações de formato da mensagem errôneas) são difíceis de lidar, porque o intermediário não pode determinar o conteúdo da mensagem. Geralmente, a melhor maneira de lidar com estas mensagens é configurando o nó de entrada para analisar e validar totalmente a mensagem. Entretanto, esta configuração se aplica somente a mensagens predefinidas; ou seja, MRM ou IDoc.

Se o nó de entrada for configurado dessa forma, os seguintes resultados serão garantidos se a mensagem de entrada não puder ser analisada com êxito.
  • A mensagem de entrada nunca é originada do terminal de saída normal do nó (ela vai para o terminal de falha).
  • A mensagem de entrada nunca entra na parte principal do fluxo de mensagens.
  • A mensagem de entrada nunca causa nenhuma atualização do banco de dados.
  • Nenhuma mensagem é gravada em nenhuma das filas de saída.

Para lidar com uma mensagem de falha, conecte um fluxo de lógica simples ao terminal de falha. A única desvantagem desta estratégia é que, se o fluxo normal não exigir acesso a todos os campos da mensagem, o ato de forçar a análise completa da mensagem afetará o desempenho.

Utilizando sua Própria Lógica para Manipular Erros do Banco de Dados

Os erros do banco de dados estão em três categorias:
  • O banco de dados não está funcionando (por exemplo, está off-line).
  • O banco de dados está funcionando mas rejeita seu pedido (por exemplo, ocorre uma contenção de bloqueio).
  • O banco de dados está funcionando mas não pode fazer o que você solicita (por exemplo, ler a partir de uma tabela não-existente).

Se você precisar de algo melhor do que a manipulação de erro padrão, a primeira etapa será utilizar uma rotina de tratamento (consulte Instrução DECLARE HANDLER) para interceptar a exceção. O manipulador pode determinar a natureza da falha do estado de SQL retornado pelo banco de dados.

Um banco de dados não está funcionando
Se um banco de dados não estiver funcionando e for essencial ao processamento de mensagens, em geral, não haverá muito a ser feito. O manipulador, tendo determinado a causa, pode concluir uma ou mais das seguintes ações:
  • Utilize a instrução RESIGNAL para emitir novamente o erro original, permitindo assim que o manipulador de erro padrão assuma o controle
  • Utilize um banco de dados diferente
  • Grave a mensagem em uma fila de saída especial

    Seja cuidadoso se usar uma abordagem semelhante a esta técnica; o manipulador absorve a exceção, portanto, todas as alterações em outros bancos de dados, ou gravações em filas, serão confirmadas.

Um banco de dados rejeita seu pedido
A situação quando uma contenção de bloqueio ocorre é semelhante ao caso de "Banco de dados não funcionando" porque o banco de dados terá restaurado todas as alterações de banco de dados feitas para a mensagem atual, não apenas para o pedido com falha. Portanto, a menos que você esteja certo de que essa tenha sido a única atualização, a manipulação de erros padrão em geral será a melhor estratégia, exceto possivelmente o log do erro ou a transmissão da mensagem para uma fila especial.
Pedidos impossíveis
Um pedido impossível ocorre quando o banco de dados está funcionando, mas não pode concluir a ação solicitada. Este tipo de erro cobre uma ampla variedade de problemas.
Se, conforme discutido no exemplo anterior, o banco de dados não tiver uma tabela do nome que o fluxo espera, a manipulação de erros padrão geralmente será a melhor estratégia, exceto possivelmente a criação de log do erro ou a transmissão da mensagem para uma fila especial.

Entretanto, muitos outros erros poderão ser tratados com êxito. Por exemplo, uma tentativa de inserir uma linha pode falhar, porque já existe esta linha e a nova linha seria uma duplicata. Ou uma tentativa de atualizar uma linha pode falhar porque não há tal linha (ou seja, a ação de atualização atualizou zero linhas). Nestes casos, o manipulador pode incorporar qualquer lógica que você achar apropriada. Ele pode inserir a linha ausente ou usar a existente (possivelmente certificando-se de que os valores nela são adequados).

Se você desejar que uma atualização de zero linhas seja relatada como um erro, é necessário configurar a propriedade Tratar Avisos como Erros no nó como true, que não é a configuração padrão.

Utilizando sua Própria Lógica para Manipular Erros em Nós de Saída

Erros que ocorrem nos nós MQOutput relatam a natureza do erro no estado SQL e fornecem informações adicionais na variável Erro Nativo de SQL. Portanto, se for exigido algo melhor que a manipulação de erros padrão, o primeiro passo será utilizar um manipulador (consulte Instrução DECLARE HANDLER) para interceptar a exceção. Esse manipulador normalmente envolve somente uma única instrução PROPAGATE.

Utilizando sua Própria Lógica para Manipular Outros Erros

Além dos erros descritos anteriormente, vários outros podem ocorrer. Por exemplo, um cálculo aritmético pode estourar, um lançamento pode falhar devido à inadequação dos dados ou um acesso a um campo de mensagem pode falhar devido a uma restrição de tipo. O intermediário oferece duas estratégias de programação para lidar com esses tipos de erro.
  • O erro causa uma exceção que é manipulada ou permanece para efetuar rollback da transação.
  • A falha é registrada como um valor especial que será testado posteriormente.

Na ausência de uma restrição de tipo, uma tentativa de acesso a um campo de mensagem não existente pode resultar no valor nulo. Os valores nulos são propagados tornando o resultado nulo. Portanto, se uma expressão, ainda que complexa, não retornar um valor nulo, você saberá que todos os valores necessários para calcular seu resultado não eram nulos.

As expressões de lançamento podem ter uma cláusula padrão. Se houver uma cláusula padrão, os lançamentos falharão de maneira silenciosa; em vez de emitir uma exceção, eles apenas retornam o valor padrão. O valor padrão pode ser um número inócuo (por exemplo, zero para um inteiro) ou um valor que seja claramente inválido no contexto (por exemplo, -1 para um número de cliente). O nulo poderá ser especificamente adequado, por ser um valor diferente dos demais e que será propagado por meio de expressões sem nenhuma possibilidade de a condição de erro ser mascarada.

Manipulando Erros em Outros Nós

As exceções que ocorrem em outros nós (ou seja, recebimento de dados de uma instrução PROPAGATE) podem ser capturadas pelos manipuladores de maneira normal. A manipulação de tais erros de forma inteligente, entretanto, sugere um problema: outro nó foi envolvido no erro original e portanto outro nó, e não necessariamente o originador da exceção, provavelmente estará envolvido na manipulação do erro.

Para ajudar nestas situações, os nós Banco de Dados e Compute possuem quatro terminais chamados Out1, Out2, Out3 e Out4. Além disso, a sintaxe da instrução PROPAGATE inclui a expressão de destino, origem da mensagem e cláusulas de controle para oferecer maior controle sobre estes terminais.

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:24


Tópico de ConceitoTópico de Conceito | Versão 8.0.0.5 | ac17140_