Résolution des erreurs d'exécution d'appel de service (Service Callout)

Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

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 d'appel de service n'est pas 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 Edge intégrées request, response et message sont de type message. Pour en savoir plus sur les variables de message, consultez la documentation de référence sur les variables.

Diagnostic

  1. Identifiez la règle d'appel de service 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 d'appel de service 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 d'appel de service. 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.

Supposons, par exemple, que la variable PostalCode référencée dans la règle d'appel de service ait été créée dans la règle d'attribution des messages suivante. Notez que PostalCode reçoit 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 d'appel de service :

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

Vérifiez que la variable définie dans l'élément <Request> de la règle d'appel de service 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 d'appel de service (comme expliqué dans la documentation relative aux règles) 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 d'attribution des messages est de type message et elle fonctionnera sans problème dans la règle d'appel de service. 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 d'appel de service n'est pas de type message de requête. Si la variable est de type message de réponse, une chaîne ou tout autre type, ce message d'erreur s'affiche.

Les variables de type message représentent des requêtes et des réponses HTTP entières. Les variables de flux Edge intégrées request, response et message sont de type message. Pour en savoir plus sur les variables de message, consultez la documentation de référence sur les variables.

Diagnostic

  1. Identifiez la règle d'appel de service 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 d'appel de service 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 d'appel de service. 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.

Supposons, par exemple, que la variable var_response référencée dans la règle d'appel de service ait été créée dans la règle d'attribution des messages 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>

N'oubliez pas que la variable var_response est utilisée dans l'élément <Request> de la règle d'appel de service.

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

Vérifiez que la variable définie dans l'élément <Request> de la règle d'appel de service ayant échoué est une variable de type message de requête qui existe. Vous pouvez également créer une variable de type message de requête directement dans la règle d'appel de service (comme expliqué dans la documentation relative aux règles) 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 d'appel de service. 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 d'appel de service 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 d'appel de service 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 le fichier faultstring suivant, le nom de la règle ServiceCallout ayant échoué est ExecuteGeocodingRequest.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

  2. Dans la règle d'appel de service 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 d'appel de service 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 ne possède pas de nom d'hôte valide. Par conséquent, la règle d'appel de service échoue en affichant le message d'erreur suivant : Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable.

Solution

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

Pour corriger la règle d'appel de service 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 le fichier 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. Consultez les playbooks sur les erreurs d'exécution (4XX/5XX) pour obtenir des instructions sur le dépannage et la résolution des erreurs 4XX ou 5XX.