Esta página se aplica à Apigee e à Apigee híbrida.
Confira a documentação da
Apigee Edge.
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, supomos que você tenha uma compreensão geral de como funciona o processamento de falhas na Apigee e 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 vão ajudar 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, a Apigee entra imediatamente no fluxo de erro e gera uma mensagem
de erro. Essa mensagem gerada pelo sistema é um objeto JSON que inclui dois bits de informação: um
errorcode e um faultstring.
Exemplo:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"mymessage message is not available for ExtractVariable: ParseJsonResponse" } }
Vamos descompilar rapidamente essa mensagem de erro:
O errorcode consiste em um prefix e um error
name, 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 ExtractVariables gerou o erro e o nome do erro é
SourceMessageNotAvailable.
O faultstring contém uma descrição do erro. A string de falha geralmente
inclui pistas para ajudar você a encontrar o problema específico que causou 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, mymessage é o nome de uma variável de mensagem não resolvida mencionada 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 em Como lidar com falhas, é prática comum interceptar os erros de política gerados pelo sistema e executar 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 a Apigee 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. É possível receber informações úteis da variável de error, como a mensagem, o código
de status, a frase de motivo e assim por diante. O padrão de formatação da variável de erro é o seguinte:
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.
Consulte a Referência de variáveis de fluxo
para informações sobre todas as variáveis da Apigee, incluindo error e
message.