Skyone
Skyone
Português
Português
  • Home
  • Dados
    • Introdução
      • Criação da conta
      • Recuperar senha
      • Guia rápido da plataforma
      • Como testar a plataforma gratuitamente
      • Espaço de trabalho
        • Criação de novo espaço
        • Encontrar um espaço
        • Enviar convite para um espaço
        • Editar um espaço
      • Organizações
        • Criando uma Organização
        • Visão Geral da Organização
        • Administração da Organização
        • Monitoramento da Organização
      • Configurações e Preferências
        • Perfil
        • Notificações
        • Uso e Pagamento
        • Usuários e permissões
    • Módulos
      • Gestão de módulos
        • Criação de Módulos
        • Importar Módulos
          • Arquivos IAC - Integration as Code
        • Edição de Módulos
        • Opções de Módulos
      • Configurações & Operações
        • Configurações de Módulos
          • Conectividade: Banco de Dados
          • Conectividade: Email
          • Conectividade: REST
          • Conectividade: SOAP
          • Conectividade: Arquivo
          • Conectividade: RFC
          • Gestão das contas conectadas
        • Operações de Módulos
          • Importar operações em módulos REST
          • Gestão das operações
        • Fluxos usando este Módulo
    • Monitoramento
    • Marketplace
    • API Gateway
    • Terminais & Agente
      • Agente
        • Versões suportadas pelo Agente
        • Como atualizar a versão do Agente
        • Como fazer backup dos arquivos do Agente
      • Terminais
    • Dados
      • Data Studio
        • Process Control
        • Data Stack Upload
        • File Actions
        • File Jobs
        • Data Job Parameters
        • Data Store
        • Data Share Features
        • ODBC
        • Como utilizar o Proxy para Data Engine
    • Integrações
      • Gestão das integrações
        • Criar integração
        • Importar integração
        • Editar integração
        • Opções da integração
        • Fluxos dessa integração
      • Fluxos
        • Gestão dos fluxos
          • Criar fluxo
          • Opções do fluxo
          • Flow Canva: configuração e edição do fluxo
            • Flow Canva: visão geral
            • Exception Handler
              • Configuração do Exception Handler
              • Cases do Exception Handler
            • Fluxos Multicontexto
              • Exemplo: Multicontexto com API Gateway
              • Exemplo: Multicontexto com Gatilho Temporal
            • Configuração do fluxo
        • Gatilhos
          • Gatilhos API Gateway: Adição e Configuração
          • Gatilhos AS2: Adição e Configuração
          • Gatilho de Fila: Adição e Configuração
          • Gatilhos de Fluxo: Adição e Configuração
          • Gatilhos Temporais: Adição e Configuração
          • Gatilhos Webhook: Adição e Configuração
        • Módulos Ferramentais
          • Módulo AS2
          • Módulo CSV
          • Módulo Chamada de Fluxo
          • Módulo Data Balancer
          • Módulo EDI
          • Módulo IF
          • Módulo JavaScript
          • Módulo Log
          • Módulo Loop Do While
          • Módulo Loop For
          • Módulo Retorno
          • Módulo Transformação de Dados
          • Módulo XML
          • Outros Módulos Ferramentais da plataforma
      • Cabeçalho dos módulos
      • Conectando componentes de um fluxo
      • Edição de gatilhos e módulos no fluxo
      • Operações de Dados
        • Manipulação de Objetos
          • Exemplo prático: Manipulação de variáveis
        • SMOP (Pequenas Operações)
        • Regras de Parametrização
    • How to
      • Inserir JSON em bancos de dados
      • Flattening: Transformação de dados utilizando JSONata
      • Como utilizar o Form Data
      • Entendendo a recursividade no JSONata
      • Consolidação de output de módulo REST
      • Como configurar um timeout de um componente?
      • Isolar na execução: conceito e aplicação em variáveis
      • Parâmetros de URL no API Gateway
      • Caso de uso: parâmetros de gatilho API Gateway
      • Caso de uso: Exception Handler em transações financeiras
      • Caso de uso: utilizando Grupos para gerenciar acessos aos fluxos
      • Como criar endpoint para download e integrar com o Power BI
      • É possível usar dois gatilhos em um único fluxo?
      • Como configurar o WhatsApp no Skyone Studio
    • FAQ
    • GIGS: O guia completo
    • Glossário
  • SUPORTE
    • Como solicitar suporte?
    • Níveis de gravidade de caso
    • SLAs
    • Ajuda e recursos
Powered by GitBook
On this page
  1. Dados
  2. Integrações
  3. Fluxos
  4. Gestão dos fluxos
  5. Flow Canva: configuração e edição do fluxo

Exception Handler

PreviousFlow Canva: visão geralNextConfiguração do Exception Handler

Last updated 9 months ago

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).

Os "Exception Handlers" podem ser aplicados a qualquer tipo de módulo, exceto os "Gatilhos".


Conceito

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.

ERROR: treatment_error
KNOWN_STACK:
component_error
execute_operation_error
http_operation_error
treatment_error <--
TREATMENT_INFO:
{
  "responseHeader": {
  "status": 400,
  "properties": {
    "content-type": "application/json",
    "content-length": "36",
    "server": "Werkzeug/2.0.2 Python/3.8.10",
    "date": "Sun, 26 Feb 2023 15:33:15 GMT"
    }
  }
}

Podemos criar uma regra para filtrar essa mensagem apenas utilizando o status code fornecido. A expressão regular será:

"status": 400

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:

  1. Seleciona o primeiro EH da lista de EHs aplicados no módulo

  2. Seleciona a primeira ER da lista de ERs dentro do EH.

  3. Avalia a expressão regular dessa ER contra a mensagem da exceção sendo analisada

  4. 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.

  5. 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.

  6. Caso não exista o match na primeira ER, a plataforma segue para a avaliação das regras seguintes.

  7. 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.

  8. Caso não exista nenhum match nas regras de um EH, a plataforma segue para a avaliação do próximo EH.

  9. Caso nenhuma ER de nenhum EH resultar em match, a plataforma irá tratar a exceção da forma tradicional.


Próximos Passos:

Configuração do Exception Handler
Cases do Exception Handler
Organização dos Exception Handlers na plataforma
Diagrama de Processamento do Exception Handler