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. Lembre-se de que no modelo transacional a mensagem de entrada com falha é retornada à fila de entrada e o intermediário tentará processá-la novamente. O resultado mais provável disso é que a mensagem continuará falhando até que seja alcançado o limite de nova tentativa e, neste ponto, ela é colocada em uma fila de devoluções. A razão para a falha ao processar a mensagem é registrada no registro de eventos do sistema (Windows) ou no syslog (UNIX). Portanto, a mensagem com falha suspende o processamento de mensagens válidas subseqüentes por um momento e, em seguida, é deixada sem ser processada pelo intermediário.
A maioria dos bancos de dados operam de forma transacional, portanto, todas as alterações feitas em tabelas de banco de dados serão confirmadas, se o processamento da mensagem for bem-sucedido e ocorrerá o rollback se ele falhar, mantendo, assim, a integridade de dados. Uma exceção para isso é que, se o próprio intermediário ou um banco de dados falhar. (Por exemplo, a energia para as máquinas nas quais eles estão em execução pode ser interrompida). Nestes casos, é possível que as alterações em alguns bancos de dados sejam confirmadas e as alterações em outros não; ou que as alterações dos bancos de dados sejam confirmadas mas as mensagens de entrada e de saída não sejam. Se estas possibilidades são motivos de preocupação, o fluxo deverá ser coordenado e os bancos de dados envolvidos configurados para esta maneira de funcionamento.
Utilize terminais de falha para captar erros não manipulados. Conecte um fluxo de lógica simples ao terminal de falha. Este fluxo de lógica pode consistir em um banco de dados ou um nó Compute que grava um registro de log em um banco de dados (possivelmente incluindo o fluxo de bits da mensagem) ou grava um registro no registro de eventos. Ele também pode conter um nó de saída que grava a mensagem em uma fila especial.
A árvore de exceções completa é transmitida para qualquer nó conectado a um terminal de falha. (A árvore de exceções está descrita em Estrutura em Árvore ExceptionList).
Para obter uma discussão detalhada das opções que podem ser utilizadas para processar erros em um fluxo de mensagens, consulte Tratando Erros em Fluxos de Mensagens. Os tópicos a seguir fornecem exemplos específicos do que pode ser feito:
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. Provavelmente, a melhor maneira de se lidar com elas é configurar o nó input para analisar e validar totalmente a mensagem.
Observe, no entanto, que isso se aplica somente a mensagens predefinidas, ou seja, MRM ou IDOC.
Para lidar com uma mensagem em falha, conecte a um fluxo lógico simples para o 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.
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. A rotina de tratamento pode determinar a natureza da falha a partir do estado de SQL retornado pelo banco de dados.
No entanto, tome cuidado com este tipo de estratégia. Como a rotina de tratamento absorve a exceção, as alterações em outros bancos de dados ou gravações em filas são confirmadas.
Os erros que ocorrem nos nós de saída do MQ relatam a natureza do erro no estado SQL e fornecem informações adicionais na variável Erro nativo de SQL. Portanto, se for requerido
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. 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 utilizados por ela 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 pode ser especificamente adequado, porque é um valor diferente de todos os outros e que será propagado por meio de expressões sem nenhuma possibilidade de a condição de erro estar sendo mascarada.
Exceções ocorridas em outros nós (ou seja, recebimento de dados de uma instrução PROPAGATE) podem ser captadas por rotinas de tratamento de maneira normal. Manipular tais erros de forma inteligente, no entanto, sugere o problema especial de que, como outro nó estava envolvido no erro original, outro nó, e não necessariamente o originador da exceção, tem grande probabilidade de estar envolvido em sua manipulação.
Para ajudar nessas situações, os nós database e compute têm quatro novos terminais chamados out1, out2, out3 e out4. Além disso, a sintaxe do Instrução PROPAGATE foi estendida para incluir expressão de destino, origem da mensagem e cláusulas de controle para fornecer maior controle sobre esses terminais extras.