Diversos problemas podem ocorrer ao interagir com sistemas externos. Esses problemas podem ser decorrentes de falhas de comunicação ou problemas no nível da aplicação. De qualquer forma, precisamos estar preparados para reagir a problemas mais comuns de forma automática ou identificar e reportar problemas não esperados. Para manipular todas as possíveis exceções vamos utilizar os "Exception Handlers" (EH).
Um "Exception Handler" é um conjunto de Exception Rules (Regras de Exceção) com uma mesma ação padrão. Os EH são aplicados a cada módulo dentro de um fluxo. Você pode aplicar múltiplos EH em um mesmo módulo para cobrir diversos tipos de exceções.
Exception Rule - ER
A unidade de identificação e tratamento de exceções é a Exception Rule - ER (Regra de Exceção). A ER contém a definição do tipo de ERRO que está se buscando tratar. Todos os erros observados em um fluxo geram algum tipo de mensagem de erro. A ER nos permite especificar uma expressão regular que é aplicada sobre essa mensagem para filtrar um tipo específico de erro.
Por exemplo, uma chamada REST que retorna um erro 400 apresenta uma mensagem de erro como abaixo.
Podemos criar uma regra para filtrar essa mensagem apenas utilizando o status code fornecido. A expressão regular será:
No mesmo ER podemos definir a quantidade de tentativas adicionais que a plataforma irá executar e o intervalo entre essas tentativas, além da notificação gerada a cada vez que a expressão é encontrada.
Default Action - DA
As ERs permitem especificar a quantidade de re-tentativas e o intervalo entre elas. Porém, quando as tentativas adicionais falham, podemos definir uma Default Action ou ação padrão que é executada ao final das tentativas.
As três ações disponíveis são:
Parar: O fluxo é interrompido completamente.
Continuar: Mesmo após a ocorrência de um erro, o fluxo continua e o erro é registrado nos logs.
Loop: Em vez de seguir adiante no fluxo, essa ação faz com que o processo retorne ao início do fluxo.
Para cada uma das ações acima é possível também definir notificações próprias e seus destinos.
Exception Handler (EH)
Podemos criar diversas ER dentro de um EH. Com isso podemos agrupar em um mesmo EH diversas regras que tenham um mesmo tratamento padrão ou Default Action (DA). Por exemplo, podemos criar duas regras específicas para tratar os códigos de resposta HTTP 404(Not Found) e 403(Forbidden), mas no caso de falha das re-tentativas, ambas serão tratadas pela mesma DA.
Módulos
Na configuração de módulo dentro do fluxo podemos especificar quais EH serão utilizados. Múltiplos EH podem ser empilhados e serão inspecionados na ordem que foram selecionados.
A possibilidade de especificar múltiplos EH em um módulo permite cobrirmos todos os tratamentos de exceções com um conjunto de EH que foram criados para lidar com exceções específicas.
Processamento
O diagrama abaixo ilustra o mecanismo de processamento dos EH.
Diagrama de Processamento do Exception Handler
Toda a chamada de um módulo pode apresentar uma exceção. Quando isso acontece, a plataforma irá verificar se existe algum EH configurado no módulo.
Quando não existe, a plataforma irá tratar a exceção da forma tradicional.
Tratamento Tradicional de Exceções
A plataforma assume o seguinte comportamento com relação as exceções na ausência de um EH:
Módulos REST: O erro é registrado nos logs de execução e torna-se disponível para manipulação pelos módulos seguintes. O fluxo segue a execução para o módulo seguinte.
Outros Módulos: O erro é registrado nos logs de execução e o fluxo é interrompido indicando falha de execução.
Tratamento de Exceções com o Exception Handler
Na presença de um ou mais EH, a plataforma segue os seguintes passos:
Seleciona o primeiro EH da lista de EHs aplicados no módulo
Seleciona a primeira ER da lista de ERs dentro do EH.
Avalia a expressão regular dessa ER contra a mensagem da exceção sendo analisada
Caso exista match (encaixe), a plataforma verifica se existe alguma notificação a ser gerada e executa. Na sequência, a plataforma verifica se existe alguma especificação de re-tentativas. Caso afirmativo, verifica se o contador de re-tentativa ainda é positivo. Nesse caso a plataforma aguarda o tempo especificado de delay antes de decrementar a quantidade de re-tentativas e retornar o fluxo para uma nova requisição da chamada.
Caso exista o match e a quantidade de re-tentativas atinja zero, a plataforma segue para a Default Action. No DA é possível especificar uma notificação distinta e tomar uma de três ações de fluxo:
a) Seguir a execução para o próximo módulo
b) Interromper a execução com respectiva geração de erro
c) Seguir para a próxima execução do loop mais interno onde se encontra o módulo.
Caso não exista o match na primeira ER, a plataforma segue para a avaliação das regras seguintes.
Caso exista uma regras com a flag ANY, a plataforma a executa como última na lista de ER e garante o seu match, independente de qualquer expressão regular.
Caso não exista nenhum match nas regras de um EH, a plataforma segue para a avaliação do próximo EH.
Caso nenhuma ER de nenhum EH resultar em match, a plataforma irá tratar a exceção da forma tradicional.
Próximos Passos:
