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.
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.
A estratégia mais simples para manipular erros ESQL é não fazer nada e utilizar o comportamento padrão do intermediário. O comportamento padrão é interromper o processamento da mensagem com falha e prosseguir para 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.
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.
Utilize os terminais de falha para capturar erros não manipulados. Conecte um fluxo de lógica simples ao terminal Failure. Esse fluxo de lógica pode consistir em um banco de dados ou um nó Cálculo que grava um registro de log em um banco de dados (possivelmente incluindo o fluxo de bits da mensagem) ou 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 Failure; consulte Estrutura em Árvore da Lista de Exceções.
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.
As mensagens de entrada sintaticamente inválidas (e mensagens de entrada que parecem inválidas devido a informações de formato de mensagem errôneo) são difíceis de lidar, porque o intermediário não sabe o que a mensagem contém. Em geral, a melhor maneira de lidar com essas mensagens é configurar o nó de entrada para analisar e validar totalmente a mensagem. Entretanto, essa configuração só se aplica a mensagens predefinidas, ou seja, MRM ou IDoc.
Para lidar com uma mensagem de falha, conecte um fluxo de lógica simples ao terminal Failure. 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.
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.
No entanto, tome cuidado com este tipo de estratégia. O manipulador absorve a exceção e por isso todas as alterações nos demais bancos de dados, ou gravações nas filas, são confirmadas.
Os erros que ocorrem nos nós MQOutput reportam a natureza do erro no estado de SQL e dão 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.
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.
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 nesses casos, os nós Banco de Dados e Cálculo possuem quatro terminais, denominados 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.