500 Erreur interne au serveur.

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Vidéos

Regardez les vidéos suivantes pour en savoir plus sur la résolution des erreurs internes du serveur (500).

Problème constaté

L'application cliente reçoit un code d'état HTTP 500 avec le message "Erreur interne du serveur" en réponse aux appels d'API. L'erreur interne du serveur (500) peut être causée par une erreur lors de l'exécution d'une règle dans Edge ou par une erreur sur le serveur cible/backend.

Le code d'état HTTP 500 est une réponse d'erreur générique. Cela signifie que le serveur a rencontré une condition inattendue qui l'a empêché de traiter la requête. Cette erreur est généralement renvoyée par le serveur lorsqu'aucun autre code d'erreur n'est approprié.

Messages d'erreur

Le message d'erreur suivant peut s'afficher :

HTTP/1.1 500 Internal Server Error

Dans certains cas, vous pouvez observer un autre message d'erreur contenant plus de détails. Voici un exemple de message d'erreur :

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Causes possibles :

L'erreur interne du serveur (500) peut être générée pour différentes raisons. Dans Edge, les causes peuvent être classées en deux catégories principales en fonction de l'endroit où l'erreur s'est produite :

Erreur d'exécution dans une règle Edge

Une règle au sein du proxy d'API peut échouer pour une raison quelconque. Cette section explique comment résoudre le problème si l'erreur interne du serveur (500) se produit lors de l'exécution d'une règle.

Diagnostic

Étapes de diagnostic pour les utilisateurs du cloud privé et public

Si vous disposez de la session d'interface utilisateur de trace pour l'erreur, procédez comme suit :

1. Vérifiez que l'erreur a été causée par l'exécution d'une règle. Pour en savoir plus, consultez Déterminer la source du problème.
2. Si l'erreur s'est produite lors de l'exécution de la règle, continuez. Si l'erreur a été causée par le serveur backend, accédez à Erreur dans le serveur backend.
3. Sélectionnez la requête d'API qui échoue avec l'erreur interne du serveur (500) dans la trace.
4. Examinez la requête et sélectionnez la règle spécifique qui a échoué ou le flux nommé "Error" qui suit immédiatement la règle ayant échoué dans la trace.
5. Obtenez plus d'informations sur l'erreur en cochant le champ "error" dans la section "Properties" ou le contenu de l'erreur.
6. À l'aide des détails que vous avez recueillis sur l'erreur, essayez de déterminer sa cause.

Étapes de diagnostic pour les utilisateurs du cloud privé uniquement

Si vous ne disposez pas de la session d'interface utilisateur de trace, procédez comme suit :

1. Vérifiez que l'erreur s'est produite lors de l'exécution d'une règle. Pour en savoir plus, consultez Déterminer la source du problème.
2. Si l'erreur a été causée par l'exécution de la règle, continuez. Si l'erreur s'est produite lors de l'exécution de la règle, continuez. Si l'erreur a été causée par le serveur backend, accédez à Erreur dans le serveur backend.
3. Utilisez les journaux d'accès NGINX, comme expliqué dans Déterminer la source du problème, pour déterminer la règle défaillante dans le proxy d'API, ainsi que l' ID unique du message de requête.
4. Consultez les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) et recherchez-y l'ID unique du message de requête.
5. Si vous trouvez l'ID unique du message de requête, voyez si vous pouvez obtenir plus d'informations sur la cause de l'échec.

Solution

Si vous avez déterminé la cause du problème lié à la règle, essayez de le corriger en modifiant la règle et en redéployant le proxy.

Les exemples suivants illustrent comment déterminer la cause et la solution pour différents types de problèmes.

Si vous avez besoin d'aide supplémentaire pour résoudre l'erreur interne du serveur (500) ou si vous pensez qu'il s'agit d'un problème dans Edge, contactez Apigee l'assistance.

Exemple 1 : Échec de la règle d'appel de service en raison d'une erreur dans le serveur backend server

Si l'appel au serveur backend échoue dans la règle d'appel de service avec une erreur telle que 4XX ou 5XX, il sera traité comme une erreur interne du serveur (500).

1. Voici un exemple où le service de backend échoue avec une erreur 404 dans la règle d'appel de service. Le message d'erreur suivant est envoyé à l'utilisateur final :

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. La session d'interface utilisateur de trace suivante affiche le code d'état 500 causé par une erreur dans la règle d'appel de service :

   

3. Dans cet exemple, la propriété "error" indique que la raison de l'échec de la règle d'appel de service est "ResponseCode 404 is treated as error" (Le code de réponse 404 est traité comme une erreur). Cette erreur peut se produire si la ressource à laquelle vous accédez via l'URL du serveur backend dans la règle d'appel de service n'est pas disponible.
4. Vérifiez la disponibilité de la ressource sur le serveur backend. Elle peut être temporairement ou définitivement indisponible, ou avoir été déplacée vers un autre emplacement.

Solution de l'exemple 1

1. Vérifiez la disponibilité de la ressource sur le serveur backend. Elle peut être temporairement ou définitivement indisponible, ou avoir été déplacée vers un autre emplacement.
2. Corrigez l'URL du serveur backend dans la règle d'appel de service pour qu'elle pointe vers une ressource valide et existante.
3. Si la ressource n'est que temporairement indisponible, essayez d'effectuer la requête d'API une fois que la ressource est disponible.

Exemple 2 : Échec de la règle d'extraction de variables

Examinons maintenant un autre exemple, où l'erreur interne du serveur (500) est causée par une erreur dans la règle d'extraction de variables, et voyons comment dépanner et résoudre le problème.

1. La trace suivante dans la session d'interface utilisateur affiche le code d'état 500 en raison d'une erreur dans la règle d'extraction de variables :

   

2. Sélectionnez la règle d'extraction de variables défaillante, faites défiler la page vers le bas et consultez la section "Error Content" (Contenu de l'erreur) pour en savoir plus :
   
   
3. Le contenu de l'erreur indique que la variable"serviceCallout.oamCookieValidationResponse" n'est pas disponible dans la règle d'extraction de variables. Comme son nom l'indique, elle doit contenir la réponse de la règle d'appel de service précédente.
4. Sélectionnez la règle d'appel de service dans la trace. Vous constaterez peut-être que la variable "serviceCallout.oamCookieValidationResponse" n'a pas été définie. Cela indique que l'appel au service de backend a échoué, ce qui a entraîné une variable de réponse vide.
5. Bien que la règle d'appel de service ait échoué, l'exécution des règles après la règle d'appel de service se poursuit, car l'indicateur "continueOnError" de la règle d'appel de service est défini sur "true", comme indiqué ci-dessous :
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. Notez l'ID unique du message "X-Apigee.Message-ID" pour cette requête d'API spécifique à partir de la trace, comme suit :
   1. Sélectionnez la phase "Analytics Data Recorded" (Données Analytics enregistrées) dans la requête.
   2. Faites défiler la page vers le bas et notez la valeur de X-Apigee.Message-ID.

   

7. Affichez le journal du processeur de messages (/opt/apigee/var/log/edge-message-processor/system.log) et recherchez l'ID unique du message noté à l'étape 6. Le message d'erreur suivant a été observé pour la requête d'API request :

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   L'erreur ci-dessus indique que la règle d'appel de service a échoué en raison d'une erreur de délai avant expiration de la connexion lors de la connexion au serveur backend.

8. Pour déterminer la cause de l'erreur de délai avant expiration de la connexion, exécutez la telnet commande sur le serveur backend à partir du ou des processeurs de messages. La commande telnet a généré l'erreur "Connection timed out" (Délai avant expiration de la connexion), comme indiqué ci-dessous :

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   En règle générale, cette erreur est observée dans les circonstances suivantes :

   • Lorsque le serveur backend n'est pas configuré pour autoriser le trafic provenant des processeurs de messages Edge.
   • Si le serveur backend n'écoute pas sur le port spécifique.

   Dans l'exemple illustré ci-dessus, bien que la règle d'extraction de variables ait échoué, la cause réelle était qu'Edge n'a pas pu se connecter au serveur backend dans la règle d'appel de service. Et la cause de cet échec était que le serveur backend n'était pas configuré pour autoriser le trafic provenant des processeurs de messages Edge.

   Votre propre règle d'extraction de variables se comportera différemment et pourra échouer pour une autre raison. Vous pouvez résoudre le problème de manière appropriée en fonction de la cause de l'échec de votre règle d'extraction de variables en vérifiant le message dans la propriété error.

Solution de l'exemple 2

1. Corrigez la cause de l'erreur ou de l'échec dans la règle d'extraction de variables de manière appropriée.
2. Dans l'exemple illustré ci-dessus, la solution consistait à rectifier la configuration réseau pour autoriser le trafic provenant des processeurs de messages Edge vers votre serveur backend. Pour ce faire, les adresses IP des processeurs de messages ont été ajoutées à la liste d'autorisation sur le serveur backend spécifique. Par exemple, sous Linux, vous pouvez utiliser iptables pour autoriser le trafic provenant des adresses IP du processeur de messages sur le serveur backend.

Exemple 3 : Échec de la règle JavaCallout

Examinons maintenant un autre exemple, où l'erreur interne du serveur (500) est causée par une erreur dans la règle JavaCallout, et voyons comment dépanner et résoudre le problème.

1. La trace d'interface utilisateur suivante affiche le code d'état 500 en raison d'une erreur dans la règle JavaCallout :

   

2. Sélectionnez le flux nommé "Error" (Erreur), suivi de la règle JavaCallout ayant échoué pour obtenir les détails de l'erreur, comme illustré dans la figure ci-dessous :

   

3. Dans cet exemple, la propriété "error" (erreur) de la section "Properties" (Propriétés) révèle que l'échec est dû à l'utilisation d'un mot de passe expiré lors de la connexion à la base de données Oracle à partir de la règle JavaCallout. Votre propre appel Java se comportera différemment et remplira un message différent dans la propriété error.
4. Vérifiez le code de la règle JavaCallout et confirmez la configuration correcte à utiliser.

Solution de l'exemple 3

Corrigez le code ou la configuration de l'appel Java de manière appropriée pour éviter l'exception d'exécution. Dans l'exemple d'échec d'appel Java illustré ci-dessus, vous devez utiliser le mot de passe correct pour vous connecter à la base de données Oracle afin de résoudre le problème.

Erreur dans le serveur backend

Une erreur interne du serveur (500) peut également provenir du serveur backend. Cette section explique comment résoudre le problème si l'erreur provient du serveur backend.

Diagnostic

Étapes de diagnostic pour tous les utilisateurs

La cause des autres erreurs backend peut varier considérablement. Vous devrez diagnostiquer chaque situation indépendamment.

1. Vérifiez que l'erreur a été causée par le serveur backend. Pour en savoir plus, consultez Déterminer la source du problème.
2. Si l'erreur a été causée par le serveur backend, continuez. Si l'erreur s'est produite lors de l'exécution de la règle, accédez à Erreur d'exécution dans une règle Edge.
3. Suivez les étapes ci-dessous, selon que vous avez ou non accès à une session de trace pour l'API défaillante, ou si le backend est un serveur Node.js :

Si vous ne disposez pas d'une session de trace pour l'appel d'API défaillant :

1. Si la trace d'interface utilisateur n'est pas disponible pour la requête défaillante, consultez les journaux du serveur backend pour obtenir des détails sur l'erreur.
2. Si possible, activez le mode débogage sur le serveur backend pour obtenir plus de détails sur l' erreur et sa cause.

Si vous disposez d'une session de trace pour l'appel d'API défaillant :

Si vous disposez d'une session de trace, les étapes suivantes vous aideront à diagnostiquer le problème.

1. Dans l'outil Trace, sélectionnez la requête d'API qui a échoué avec l'erreur interne du serveur (500) .
2. Sélectionnez la phase "Response received from target server" (Réponse reçue du serveur cible) dans la requête d'API défaillante comme illustré dans la figure ci-dessous :

   

3. Consultez la section "Response Content" (Contenu de la réponse) pour obtenir des détails sur l'erreur.

   

4. Dans cet exemple, le contenu de la réponse, qui est une enveloppe SOAP, affiche la chaîne d'erreur sous la forme du message "Not Authorized" . La cause la plus probable de ce problème est que l'utilisateur ne transmet pas les identifiants appropriés (nom d'utilisateur/mot de passe, jeton d'accès, etc.) au serveur backend. Vous pouvez résoudre ce problème en transmettant les identifiants corrects au serveur backend.

Si le backend est un serveur Node.js :

1. Si le backend est un serveur backend Node.js, consultez les journaux Node.js pour le proxy d'API spécifique dans l'interface utilisateur Edge (les utilisateurs du cloud public et privé peuvent consulter les journaux Node.js). Si vous êtes un utilisateur du cloud privé Edge, vous pouvez également consulter les journaux de votre processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) pour obtenir plus de détails sur l'erreur.
   
   

   Option "NodeJS Logs" (Journaux NodeJS) dans l'interface utilisateur Edge – Onglet "Overview" (Présentation) du proxy d'API

   

Solution

1. Une fois que vous avez identifié la cause de l'erreur, corrigez le problème sur votre serveur backend.
2. S'il s'agit d'un serveur backend Node.js :
   1. Vérifiez si l'erreur est générée par votre code personnalisé et corrigez le problème si possible.
   2. Si l'erreur n'est pas générée par votre code personnalisé ou si vous avez besoin d'aide, contactez l'assistance Apigee.

Si vous avez besoin d'aide supplémentaire pour résoudre l'erreur interne du serveur (500) ou si vous pensez qu'il s'agit d'un problème dans Edge, contactez Apigee l'assistance.

Déterminer la source du problème

Utilisez l'une des procédures suivantes pour déterminer si l'erreur interne du serveur (500) a été générée lors de l'exécution d'une règle dans le proxy d'API ou par le serveur backend.

Utiliser la trace dans l'interface utilisateur

Remarque : Les étapes de cette section peuvent être effectuées par les utilisateurs du cloud public et privé.

1. Si le problème est toujours actif, activez la trace dans l'interface utilisateur pour l'API concernée.
2. Une fois la trace capturée, sélectionnez la requête d'API qui affiche le code de réponse comme 500.
3. Parcourez toutes les phases de la requête d'API défaillante et vérifiez quelle phase renvoie l'erreur interne du serveur (500) :
   1. Si l'erreur est générée lors de l'exécution d'une règle, passez à Erreur d'exécution dans une règle Edge.
   2. Si le serveur backend a répondu avec l'erreur interne du serveur (500), passez à Erreur dans le serveur backend.

Utiliser la surveillance des API

Remarque : Les étapes de cette section ne peuvent être effectuées que par les utilisateurs du cloud public.

La surveillance des API vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence et leur source, tels que les applications de développeur, les proxys d'API, les cibles backend ou la plate-forme d'API.

Parcourez un exemple de scénario qui montre comment résoudre les problèmes 5xx avec vos API à l'aide de la surveillance des API. Par exemple, vous pouvez configurer une alerte pour être averti lorsque le nombre de codes d'état 500 ou de défauts steps.servicecallout.ExecutionFailed dépasse un seuil particulier.

Utiliser les journaux d'accès NGINX

Remarque : Les étapes de cette section ne concernent que les utilisateurs du cloud privé Edge uniquement.

Vous pouvez également consulter les journaux d'accès NGINX pour déterminer si le code d'état 500 a été généré lors de l'exécution d'une règle dans le proxy d'API ou par le serveur backend. Cela est particulièrement utile si le problème s'est produit dans le passé ou s'il est intermittent et que vous ne parvenez pas à capturer la trace dans l'interface utilisateur. Procédez comme suit pour déterminer ces informations à partir des journaux d'accès NGINX :

1. Consultez les journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
2. Recherchez les éventuelles erreurs 500 pour le proxy d'API spécifique pendant la durée spécifique.
3. S'il existe des erreurs 500, vérifiez s'il s'agit d'une erreur de règle ou de serveur cible, comme indiqué ci-dessous :

   Exemple d'entrée montrant une erreur de règle

   

   Exemple d'entrée montrant une erreur de serveur cible

   

4. Une fois que vous avez identifié s'il s'agit d'une erreur de règle ou de serveur cible :
   1. Passez à Erreur d'exécution dans une règle Edge si il s'agit d'une erreur de règle.
   2. Passez à Erreur dans le serveur backend s'il s'agit d'une erreur de serveur cible.