Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a documentação do
Apigee Edge.
Este tópico descreve a estrutura dos erros de políticas e os tipos de variáveis de fluxo que são definidas quando ocorre um erro de política. Estas informações são essenciais se estiver a conceber e a implementar o processamento de falhas para os seus proxies.
Este tópico pressupõe que tem uma compreensão geral de como funciona o processamento de falhas no Apigee e que sabe o que são regras de falhas. Se precisar de uma revisão, consulte o artigo Como lidar com falhas. As informações aqui apresentadas também ajudam a navegar e usar a referência de erros de políticas.
Acerca da resposta de erro da política predefinida
Quando uma política gera um erro, o Apigee entra imediatamente no fluxo de erros e gera uma mensagem de erro. Esta mensagem gerada pelo sistema é um objeto JSON que inclui dois fragmentos de informações: um errorcode e um faultstring.
Por exemplo:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"mymessage message is not available for ExtractVariable: ParseJsonResponse" } }
Vamos analisar rapidamente esta mensagem de erro:
O errorcode consiste num prefix e num error
name, da seguinte forma: [prefix].[error_name]. No exemplo acima,
"steps.extractvariables" é o prefixo e SourceMessageNotAvailable é
o nome do erro. O prefixo indica o tipo de política que gerou o erro. No exemplo acima, pode ver que uma política ExtractVariables gerou o erro e que o nome do erro é SourceMessageNotAvailable.
O elemento faultstring contém uma descrição do erro. Normalmente, a string de falha inclui pistas para ajudar 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 quer que tenha contribuído para o erro. Por exemplo, na mensagem de erro acima, mymessage é 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íticas
Quando é acionado um erro de política, são preenchidas determinadas variáveis de fluxo específicas do erro. Estas variáveis são extremamente úteis no processamento de falhas. Conforme explicado em Processar 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, pode querer impedir que os clientes vejam os erros reais e os códigos de estado que o Apigee devolve.
A variável fault.name
Quando uma política gera um erro, define a variável de fluxo fault.name para a parte error_name do código de erro (conforme descrito na secção anterior). É muito comum avaliar esta variável para executar condicionalmente regras de falhas.
Segue-se um exemplo de uma 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>O que deve lembrar-se é 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 programadores verificam frequentemente é a flag [prefix].[policy_name].failed, que é definida como verdadeira ou falsa quando uma política é executada. Nas regras de falha, é recomendável verificar quando é verdadeiro, ou seja, verificar se ocorreu um erro. Veja como criar uma condição que verifique a flag [prefix].[policy_name].failed. Para verificar corretamente esta variável, tem de saber duas coisas:
- O nome da política que está a verificar. Este é o valor do atributo name da política e não o nome a apresentar. Este atributo está sempre incluído no XML da definição da política.
- Um prefixo específico do tipo de política que está a verificar. (Explicamos como encontrar o prefixo abaixo.)
Para ilustrar, segue-se outro exemplo de regra de falha. Repare na condição externa como o nome da variável [prefix].[policy_name].failed é formado. Neste caso, o prefixo é extractvariables e o nome da política é ParseJsonResponse. Neste caso, a regra de falha só é executada se esta variável for verdadeira. Além disso, aqui tem uma sugestão: uma vez que as regras de falhas podem conter vários passos, este padrão é uma boa forma de organizar as regras de falhas 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>
Acerca das variáveis
error e message
A variável error só está disponível no fluxo de erros de um proxy. Pode obter informações úteis da variável error, como a mensagem de erro, o código de estado, entre outros. O padrão de formatação da variável de erro é o seguinte:
error.ERROR_COMPONENT = VALUE
Por 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 aos da variável error. A variável de mensagem é especial porque é contextual. Num fluxo de pedidos, comporta-se como uma variável de pedido e, num fluxo de respostas, pode ser usado para obter/definir valores de resposta.
Consulte a referência de variáveis de fluxo
para obter informações sobre todas as variáveis do Apigee, incluindo error e
message.