O que você precisa saber sobre erros de política

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Neste tópico, descrevemos a estrutura dos erros de política e os tipos de variáveis de fluxo que são definidas quando ocorre um erro de política. Essas informações são essenciais para projetar e implementar o tratamento de falhas para seus proxies.

Neste tópico, pressupõe-se que você tenha uma compreensão geral de como o tratamento de falhas funciona no Edge e que você sabe o que são regras de falha. Se você precisar de uma revisão, consulte Como lidar com falhas. Essas informações também ajudarão você a navegar e usar a Referência de erros da política.

Sobre a resposta de erro de política padrão

Quando uma política gera um erro, o Edge entra imediatamente no fluxo de erro e gera um erro mensagem. Essa mensagem gerada pelo sistema é um objeto JSON que inclui dois bits de informação: um errorcode e uma faultstring.

Exemplo:

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.extractvariables.SourceMessageNotAvailable"
      },
      "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse"
   }
}

Vamos descompilar rapidamente essa mensagem de erro:

O errorcode consiste em um prefixo e um nome do erro, da seguinte maneira: [prefix].[error_name]. No exemplo acima, "steps.extractvariables" é o prefixo e SourceMessageNotAvailable é o nome do erro. O prefixo informa o tipo de política que gerou o erro. No exemplo acima, é possível dizer que uma política de extração de variáveis gerou o erro e o nome do erro é SourceMessageNotAvailable.

A faultstring contém uma descrição do erro. A string de falha geralmente inclui pistas para ajudar você a encontrar problemas específicos que causaram o erro, como o nome da política, o nome de uma variável não resolvida ou o que contribuiu para o erro. Por exemplo, na mensagem de erro acima, "foo" é o nome de uma variável de mensagem não resolvida referenciada na política e "ParseJsonResponse" é o nome da política que acionou o erro.

Variáveis específicas de erros de política

Quando um erro de política é acionado, determinadas variáveis de fluxo específicas do erro são preenchidas. Essas variáveis são extremamente úteis no gerenciamento de falhas. Como explicado no tópico Tratamento de falhas, é comum detectar os erros de política gerados pelo sistema e realizar uma ação subsequente, como criar um uma resposta de erro personalizada. Por exemplo, por motivos de segurança, convém impedir que os clientes ver os erros reais e os códigos de status retornados pelo Edge.

A variável fault.name

Quando uma política gera um erro, ela define a variável de fluxo fault.name como a parte error_name do código de erro (conforme descrito na seção anterior). É muito comum avaliar essa variável para executar regras de falha condicionalmente.

Veja um exemplo de regra de falha que testa o valor de fault.name:

<faultrule name="VariableOfNonMsgType"<>/faultrule><FaultRule name="Source Message Not Available Fault">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
</FaultRule>

Lembre-se de que, quando uma política aciona um erro, a variável fault.name é sempre definida como o nome do erro.

A variável [prefix].[policy_name].failed

Além de fault.name, outra variável que os desenvolvedores geralmente verificam é a sinalização [prefix].[policy_name].failed, que é definida como verdadeira ou falsa quando uma política é executada. Nas regras de falha, verifique se é verdadeiro, ou seja, verifique se ocorreu um erro. Veja como criar uma condicional que verifica a sinalização [prefix].[policy_name].failed. Para verificar corretamente essa variável, você precisa saber duas coisas:

• O nome da política que você está verificando. Esse é o valor do atributo de nome da política, não do nome de exibição. Esse atributo é sempre incluído no XML da definição da política.
• Um prefix específico para o tipo de política que você está verificando. Explicaremos como encontrar o prefixo abaixo.

Veja a seguir outro exemplo de regra de falha. Observe na condição externa como o nome da variável [prefix].[policy_name].failed é formado. Nesse caso, o prefixo é extractvariables e o nome da política é ParseJsonResponse. Nesse caso, a regra de falha só será executada se essa variável for verdadeira. E aqui está uma dica: como as regras de falha podem conter várias etapas, esse padrão é uma boa maneira de organizar regras de falha em blocos.

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults">
    <Step>
        <Name>AM-CustomErrorMessage</Name>
        <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition>
    </Step>
    <Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition>
</FaultRule>

Sobre as variáveis error e message

A variável error está disponível apenas no fluxo de erros de um proxy. Você pode receber informações úteis da variável de erro, como a mensagem, o código de status, a frase de motivo e assim por diante. O padrão de formatação para a variável de erro é:

error.[error_component] = [value]

Exemplo:

error.message = "request message is not available for ExtractVariable: ParseJsonResponse"

e

error.status.code = "500"

A variável message também está disponível no fluxo de erros e pode ser usada para fins semelhantes à variável error. A variável de mensagem é especial porque é contextual. Em um fluxo de solicitação, ele se comporta como uma variável de solicitação e, em um fluxo de resposta, pode ser usado para conseguir/definir valores de resposta. Se você quiser saber mais, consulte Casos de uso para variáveis de mensagens.

Consulte a Referência de variáveis. para saber mais sobre todas as variáveis do Edge, incluindo error e message.