Résolution des erreurs d'exécution de la règle ServiceCallout

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

RequestVariableNotMessageType

Code d'erreur

steps.servicecallout.RequestVariableNotMessageType

Corps de la réponse d'erreur

{
    "fault": {
        "faultstring": "ServiceCallout[POLICY_NAME]: request variable [VARIABLE_NAME] value is not of type Message",
        "detail": {
            "errorcode": "steps.servicecallout.RequestVariableNotMessageType"
        }
    }
}

Cause

Cette erreur se produit si une variable spécifiée dans l'élément <Request> de la règle ServiceCallout est de type message. Si la variable est une chaîne ou de type autre que Message, le message d'erreur suivant s'affiche.

Les variables de type Message représentent des requêtes et des réponses HTTP entières. Les variables de flux intégrées request, response et message sont de type message.

Diagnostic

  1. Identifiez la règle ServiceCallout où l'erreur s'est produite et le nom de la variable dont le type est incorrect. Vous pouvez trouver ces deux éléments dans l'élément faultstring de la réponse d'erreur. Par exemple, dans le fichier faultstring suivant, le nom de la règle est ExecuteGeocodingRequest et celui de la variable est PostalCode :

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"

  2. Dans le fichier XML de la règle ServiceCallout ayant échoué, vérifiez que le nom de la variable définie dans l'élément <Request> correspond au nom de la variable identifiée dans la chaîne d'erreur (étape 1 ci-dessus). Par exemple, la règle suivante spécifie une variable de requête nommée PostalCode, qui correspond au contenu de faultstring :

    <?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>

  3. Déterminez si cette variable est de type message ou non :

    1. Recherchez le code dans le groupe de proxys d'API, où la variable a été définie en premier.
    2. Dans la plupart des cas, vous constaterez que la variable posant problème est créée et insérée dans une autre règle qui s'exécute avant la règle ServiceCallout. Par exemple, la règle d'attribution des messages est couramment utilisée pour créer et insérer des variables dans un flux de proxy d'API.
    3. Une fois que vous avez identifié la règle où la variable est définie et renseignée en premier, vous devez déterminer le type de cette variable comme suit :
      • Vérifiez la valeur de l'attribut type (le cas échéant).
      • En l'absence d'attribut type, la variable est considérée comme une chaîne.
    4. Si la variable n'est pas de type message (par exemple, une chaîne), il s'agit de la cause de l'erreur. Pour en savoir plus sur les variables courantes et leurs types, consultez la documentation de référence sur les variables de flux.

Supposons, par exemple, que la variable PostalCode référencée dans la règle ServiceCallout ait été créée dans la règle AssignMessage suivante. Notez que PostalCode se voit attribuer la valeur de la variable de flux request.queryparam.postalcode. Cette valeur est une chaîne, car il n'y a pas d'attribut type dans l'attribution de variable.

<?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>

Rappelez-vous que la variable PostalCode est utilisée dans l'élément <Request> de la règle 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>

Comme PostalCode n'est pas de type message (il s'agit d'une chaîne dans cet exemple), vous obtenez le code d'erreur suivant : steps.servicecallout.RequestVariableNotMessageType.

Solution

Assurez-vous que la variable définie dans l'élément <Request> de la règle ServiceCallout ayant échoué est une variable de flux de type message qui existe. Vous pouvez également créer une variable de type message directement dans la règle ServiceCallout (comme expliqué sur la page Règle ServiceCallout) et l'utiliser.

Pour corriger la règle, vous devez modifier l'élément <Request> afin de spécifier une variable existante ou une nouvelle variable de type message. Par exemple, la variable GeocodingRequest définie dans la règle AssignMessage est de type message, et elle fonctionnera sans problème dans la règle ServiceCallout. Exemple :

<?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

Code d'erreur

steps.servicecallout.RequestVariableNotRequestMessageType

Corps de la réponse d'erreur

{
    "fault": {
        "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Request Message",
        "detail": {
            "errorcode": "steps.servicecallout.RequestVariableNotRequestMessageType"
        }
    }
}

Cause

Cette erreur se produit si une variable spécifiée dans l'élément <Request> de la règle ServiceCallout est de type message. Si la variable est de type message de réponse, une chaîne ou tout autre type, ce message d'erreur s'affiche.

La variable de type message représente des requêtes et des réponses HTTP entières. Les variables de flux intégrées request, response et message sont de type message.

Diagnostic

  1. Identifiez la règle ServiceCallout où l'erreur s'est produite et le nom de la variable dont le type est incorrect. Vous pouvez trouver ces deux éléments dans l'élément faultstring de la réponse d'erreur. Par exemple, dans le fichier faultstring suivant, le nom de la règle est ExecuteGeocodingRequest et celui de la variable est var_response :

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"

  2. Dans le fichier XML de la règle ServiceCallout ayant échoué, vérifiez que le nom de la variable définie dans l'élément <Request> correspond au nom de la variable identifiée dans la chaîne d'erreur (étape 1 ci-dessus). Par exemple, la règle suivante spécifie une variable de requête nommée var_response, qui correspond au contenu de faultstring :

    <?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>

  3. Déterminez si la variable est de type message de requête ou pas :

    1. Recherchez le code dans le groupe de proxys d'API, où la variable a été définie en premier.
    2. Dans la plupart des cas, vous constaterez que la variable posant problème est créée et insérée dans une autre règle qui s'exécute avant la règle ServiceCallout. Par exemple, la règle d'attribution des messages est couramment utilisée pour créer et insérer des variables dans un flux de proxy d'API.
    3. Une fois que vous avez identifié la règle où la variable est définie et renseignée en premier, vous devez déterminer le type de cette variable comme suit :
      • Vérifiez la valeur de l'attribut type (le cas échéant).
      • En l'absence d'attribut type, la variable est considérée comme une chaîne.
    4. Si le type de la variable n'est pas du type message de requête, il s'agit de la cause de l'erreur. Pour en savoir plus sur les variables courantes et leurs types, consultez la documentation de référence sur les variables de flux.

Supposons, par exemple, que la variable var_response référencée dans la règle ServiceCallout ait été créée dans la règle AssignMessage suivante. La variable response est associée au type var_response. Par conséquent, la variable var_response est de type message de réponse.

<?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>

Rappelez-vous que la variable var_response est utilisée dans l'élément <Request> de la règle 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>

Comme var_response n'est pas de type message de requête mais de type message de réponse, vous obtenez le code d'erreur suivant : steps.servicecallout.RequestVariableNotRequestMessageType.

Solution

Assurez-vous que la variable définie dans l'élément <Request> de la règle ServiceCallout ayant échoué est une variable de type message qui existe. Vous pouvez également créer une variable de type message de requête directement dans la règle ServiceCallout (comme expliqué sur la page Règle ServiceCallout) et l'utiliser.

Pour corriger la règle, vous devez modifier l'élément <Request> afin de spécifier une variable existante ou une nouvelle variable de type message de requête qui fonctionnera dans la règle ServiceCallout. Exemple :

<?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

Code d'erreur

steps.servicecallout.ExecutionFailed

Corps de la réponse d'erreur

{
    "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"
        }
    }
}

Causes possibles

Les causes possibles de cette erreur sont les suivantes :

Cause Description
Requête non valide ou incorrecte L'URL cible de la règle ServiceCallout est incorrecte, ou son nom d'hôte est non valide ou inaccessible.
Erreur du serveur backend Le serveur backend renvoie une réponse d'erreur 4XX ou 5XX.

Cause : URL incorrecte ou non valide

L'URL cible de la règle ServiceCallout est incorrecte, ou son nom d'hôte est non valide ou inaccessible.

Diagnostic

  1. Identifiez la règle ServiceCallout à l'origine de l'erreur. Le nom de la règle apparaît dans l'élément faultstring de la réponse d'erreur. Par exemple, dans l'élément faultstring suivant, le nom de la règle ServiceCallout ayant échoué est ExecuteGeocodingRequest.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

  2. Dans la règle ServiceCallout ayant échoué, examinez l'élément <URL>. S'il est incorrect, ou si le nom d'hôte est non valide ou inaccessible, il s'agit de la cause de l'erreur. Par exemple, la règle ServiceCallout suivante spécifie un élément <URL> non valide :

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
    <Request variable="GeocodingRequest"/>
    <Response>GeocodingResponse</Response>
    <HTTPTargetConnection>
        <URL>http://</URL>
    </HTTPTargetConnection>
</ServiceCallout>

    L'élément <URL> ne possède que le protocole http://, mais n'a pas de nom d'hôte valide. Par conséquent, la règle ServiceCallout échoue avec l'erreur suivante : Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable.

Solution

Assurez-vous que l'élément <URL> de la règle ServiceCallout ayant échoué possède une URL valide avec un nom d'hôte accessible.

Pour corriger la règle ServiceCallout présentée ci-dessus, vous pouvez modifier l'élément <URL> pour spécifier une URL valide :

<?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>

Cause : erreur du serveur backend

Le serveur backend renvoie une réponse d'erreur 4XX ou 5XX.

Diagnostic

  1. Identifiez la règle ServiceCallout à l'origine de l'erreur. Le nom de la règle apparaît dans l'élément faultstring de la réponse d'erreur. Par exemple, dans l'élément faultstring suivant, le nom de la règle ServiceCallout ayant échoué est ExecuteGeocodingRequest.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]

  2. Examinez faultstring dans le corps de la réponse d'erreur et vérifiez si des codes de réponse 4XX ou 5XX sont répertoriés dans Reason. Par exemple, la chaîne d'erreur suivante indique clairement qu'un code de réponse 502 a été renvoyé par le serveur backend :

    "faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"

Solution

Une fois que vous avez déterminé le code de réponse d'erreur, vous pouvez résoudre ce problème comme vous le feriez pour une erreur 4XX ou 5XX.