Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.
RequestVariableNotMessageType
Código do erro
steps.servicecallout.RequestVariableNotMessageType
Corpo da resposta de erro
{ "fault": { "faultstring": "ServiceCallout[POLICY_NAME]: request variable [VARIABLE_NAME] value is not of type Message", "detail": { "errorcode": "steps.servicecallout.RequestVariableNotMessageType" } } }
Causa
Esse erro ocorrerá se uma variável especificada no elemento <Request>
da política ServiceCallout não for do tipo message
. Se a variável for uma string ou qualquer outro tipo de não mensagem, você verá esse erro.
As variáveis do tipo Message representam solicitações e respostas HTTP completas. As variáveis de fluxo integradas request
, response
e message
são do tipo message
.
Diagnóstico
Identifique a política ServiceCallout em que o erro ocorreu e o nome da variável com o tipo incorreto. É possível encontrar os dois itens no elemento
faultstring
da resposta de erro. Por exemplo, nofaultstring
a seguir, o nome da política éExecuteGeocodingRequest
e a variável éPostalCode
:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"
No XML de política ServiceCallout com falha, verifique se o nome da variável definida no elemento
<Request>
corresponde ao nome da variável identificada na string com falha (etapa 1 acima). Por exemplo, a política a seguir especifica uma variável de solicitação chamadaPostalCode
, que corresponde ao que está nafaultstring
:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="PostalCode"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
Determine se essa variável é do tipo mensagem ou não:
- Localize o código no pacote do proxy de API em que a variável foi definida primeiro.
- Na maioria dos casos, a variável com problema é criada e preenchida em outra política que é executada antes da política ServiceCallout. Por exemplo, a política "Atribuir mensagem" é comumente usada para criar e preencher variáveis em um fluxo de proxy de API.
- Depois de descobrir a política em que a variável é definida e preenchida primeiro, você precisará determinar o tipo dessa variável da seguinte forma:
- Verifique o valor do atributo
type
(se presente). - Se o atributo
type
não estiver presente, a variável será considerada uma string.
- Verifique o valor do atributo
- Se o tipo da variável for não mensagem (como uma string), essa é a causa do erro. Saiba mais sobre as variáveis comuns e os tipos delas em Referência de variáveis de fluxo.
Por exemplo, suponha que a variável PostalCode
referenciada na política ServiceCallout foi criada na seguinte política AssignMessage. Observe que PostalCode
recebe o valor da variável de fluxo request.queryparam.postalcode
. Esse valor é uma string porque não há um atributo type
presente na atribuição de variável.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage name="GenerateGeocodingRequest">
<AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
<Set>
<QueryParams>
<QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
<QueryParam name="region">{request.queryparam.country}</QueryParam>
<QueryParam name="sensor">false</QueryParam>
</QueryParams>
<Verb>GET</Verb>
</Set>
<AssignVariable>
<Name>PostalCode</Name>
<Ref>request.queryparam.postalcode</Ref>
</AssignVariable>
<AssignVariable>
<Name>Country</Name>
<Ref>request.queryparam.country</Ref>
</AssignVariable>
</AssignMessage>
Agora, lembre-se de que a variável PostalCode
é usada no elemento <Request>
da política ServiceCallout:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="PostalCode"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
Como PostalCode
não é do tipo mensagem (ele é uma string neste exemplo), você recebe o código de erro: steps.servicecallout.RequestVariableNotMessageType
.
Resolução
Verifique se a variável definida no elemento <Request>
na política ServiceCallout com falha é uma variável de fluxo de tipo message
que existe. Ou crie uma nova variável de tipo mensagem diretamente na política ServiceCallout (conforme explicado na política ServiceCallout) e use-a.
Para corrigir a política, é necessário modificar o elemento <Request>
para especificar uma variável nova ou atual que seja do tipo mensagem. Por exemplo, a variável GeocodingRequest
que foi definida na política "Atribuir mensagem" é do tipo "mensagem" e funciona bem na política ServiceCallout. Exemplo:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="GeocodingRequest"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
RequestVariableNotRequestMessageType
Código do erro
steps.servicecallout.RequestVariableNotRequestMessageType
Corpo da resposta de erro
{ "fault": { "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Request Message", "detail": { "errorcode": "steps.servicecallout.RequestVariableNotRequestMessageType" } } }
Causa
Esse erro ocorrerá se uma variável especificada no elemento <Request>
da política ServiceCallout não for do tipo message
. Se a variável for um tipo de mensagem de resposta, uma string ou qualquer outro tipo, você verá esse erro.
A variável do tipo message
representa solicitações HTTP e respostas inteiras. As variáveis de fluxo integradas request
, response
e message
são do tipo message
.
Diagnóstico
Identifique a política ServiceCallout em que o erro ocorreu e o nome da variável com o tipo incorreto. É possível encontrar os dois itens no elemento
faultstring
da resposta de erro. Por exemplo, nofaultstring
a seguir, o nome da política éExecuteGeocodingRequest
e a variável évar_response
:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"
No XML de política ServiceCallout com falha, verifique se o nome da variável definida no elemento
<Request>
corresponde ao nome da variável identificada na string com falha (etapa 1 acima). Por exemplo, a política a seguir especifica uma variável de solicitação chamadavar_response
, que corresponde ao que está nafaultstring
:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="var_response"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
Determine se a variável é do tipo de mensagem de solicitação ou não:
- Localize o código no pacote do proxy de API em que a variável foi definida primeiro.
- Na maioria dos casos, a variável com problema é criada e preenchida em outra política que é executada antes da política ServiceCallout. Por exemplo, a política "Atribuir mensagem" é comumente usada para criar e preencher variáveis em um fluxo de proxy de API.
- Depois de descobrir a política em que a variável é definida e preenchida primeiro, você precisará determinar o tipo dessa variável da seguinte forma:
- Verifique o valor do atributo
type
(se presente). - Se o atributo
type
não estiver presente, a variável será considerada uma string.
- Verifique o valor do atributo
- Se o tipo da variável não for do tipo mensagem de solicitação, essa é a causa do erro. Saiba mais sobre as variáveis comuns e os tipos delas em Referência de variáveis de fluxo.
Por exemplo, suponha que a variável var_response
referenciada na política ServiceCallout foi criada na seguinte política "Atribuir mensagem". Observe que var_response
recebe o tipo response
. Portanto, o tipo da variável var_response
é uma mensagem de resposta.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage name="GenerateGeocodingRequest">
<AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
<AssignTo createNew="true" type="response">var_response</AssignTo>
<Set>
<QueryParams>
<QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
<QueryParam name="region">{request.queryparam.country}</QueryParam>
<QueryParam name="sensor">false</QueryParam>
</QueryParams>
<Verb>GET</Verb>
</Set>
<AssignVariable>
<Name>PostalCode</Name>
<Ref>request.queryparam.postalcode</Ref>
</AssignVariable>
<AssignVariable>
<Name>Country</Name>
<Ref>request.queryparam.country</Ref>
</AssignVariable>
</AssignMessage>
Lembre-se de que a variável var_response
é usada no elemento <Request>
da política ServiceCallout.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="var_response"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
Como var_response
não é do tipo mensagem de solicitação (o tipo dele é mensagem de resposta), você recebe o código de erro: steps.servicecallout.RequestVariableNotRequestMessageType
.
Resolução
Verifique se a variável definida no elemento <Request>
na política ServiceCallout com falha é uma variável de fluxo de tipo message
que existe. Ou crie uma nova variável de tipo mensagem de solicitação diretamente na política ServiceCallout (conforme explicado na política ServiceCallout) e use-a.
Para corrigir a política, modifique o elemento <Request>
para especificar uma variável existente ou nova que seja do tipo mensagem de solicitação, e ela funcionará na política ServiceCallout. Exemplo:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="GeocodingRequest"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
ExecutionFailed
Código do erro
steps.servicecallout.ExecutionFailed
Corpo da resposta de erro
{ "fault": { "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: Host not reachable", "detail": { "errorcode": "steps.servicecallout.ExecutionFailed" } } }
ou
{ "fault": { "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: ResponseCode [http_code] is treated as error", "detail": { "errorcode": "steps.servicecallout.ExecutionFailed" } } }
Causas possíveis
Veja a seguir as possíveis causas para esse erro:
Causa | Descrição |
URL inválido ou incorreto | O URL de destino na política ServiceCallout está incorreto ou tem um nome de host inválido ou inacessível. |
Erro no servidor de back-end | O servidor de back-end retorna uma resposta de erro de 4XX ou 5XX. |
Causa: URL inválido ou incorreto
O URL de destino na política ServiceCallout está incorreto ou tem um nome de host inválido ou inacessível.
Diagnóstico
Identifique a política ServiceCallout que causou o erro. O nome da política aparece no elemento
faultstring
da resposta de erro. Por exemplo, nofaultstring
a seguir, o nome da política ServiceCallout com falha éExecuteGeocodingRequest
."faultstring": "ServiceCallout[ExecuteGeocodingRequest]"
Na política ServiceCallout com falha, examine o elemento
<URL>
. Se a formatação for incorreta ou tiver um nome de host inválido ou inacessível, essa será a causa do erro. Por exemplo, a seguinte política ServiceCallout especifica um<URL>
inválido:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="GeocodingRequest"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://</URL> </HTTPTargetConnection> </ServiceCallout>
O elemento
<URL>
só tem o protocolohttp://
, mas não tem um nome de host válido. Por isso, a política ServiceCallout falha com o erro:Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable
.
Resolução
Verifique se o elemento <URL>
na política ServiceCallout com falha tem um URL válido com um nome de host acessível.
Para corrigir a política ServiceCallout mostrada acima, modifique o elemento <URL>
para especificar um URL válido:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="GeocodingRequest"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
Causa: erro no servidor de back-end
O servidor de back-end retorna uma resposta de erro de 4XX ou 5XX.
Diagnóstico
Identifique a política ServiceCallout que causou o erro. O nome da política aparece no elemento
faultstring
da resposta de erro. Por exemplo, nofaultstring
a seguir, o nome da política ServiceCallout com falha éExecuteGeocodingRequest
."faultstring": "ServiceCallout[ExecuteGeocodingRequest]
Analise o
faultstring
no corpo da resposta de erro e verifique se há códigos de resposta 4XX ou 5XX listados emReason
. Por exemplo, a seguinte string de falha indica claramente que um código de resposta 502 foi retornado do servidor de back-end:"faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"
Resolução
Após determinar o código de resposta de erro, você poderá solucionar o problema da mesma forma que faria com qualquer erro 4XX ou 5XX.