Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da
Apigee X. info
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, presume-se que você tenha uma compreensão geral de como o tratamento de falhas funciona no Edge e que saiba 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 erros e gera uma mensagem de erro. 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. Conforme explicado no tópico Como lidar com falhas, é uma prática comum capturar os erros de política gerados pelo sistema e realizar uma ação subsequente, como criar uma resposta de erro personalizada. Por exemplo, por motivos de segurança, talvez você queira evitar que os clientes vejam os erros reais e os códigos de status que o Edge retorna.
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 informações sobre todas as variáveis do Edge, incluindo error e
message.