Cette page a été traduite par l'API Cloud Translation.

Échec de la configuration des erreurs de déploiement

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

Le déploiement des révisions de proxy d'API ou de flux partagé via l'interface utilisateur Edge ou l'API de gestion échoue avec une erreur Échec de la configuration.

Message d'erreur

Vous obtiendrez un message d'erreur dans l'interface utilisateur Edge comme indiqué ci-dessous:

The revision is deployed, but traffic cannot flow.
com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}

Voici la capture d'écran d'un exemple de message d'erreur observé dans l'interface utilisateur Edge:

Causes possibles :

Le déploiement d'un proxy d'API peut échouer et renvoyer l'erreur "Échec de la configuration" pour de nombreuses raisons. Le tableau ci-dessous répertorie quelques causes fréquemment observées qui provoquent cette erreur :

Cause	Description	Instructions de dépannage applicables à
Classe Java manquante dans la règle JavaCallout	Il manque une classe Java dans le fichier JAR référencé par la règle JavaCallout.	Utilisateurs de cloud privé périphérique
Des opérandes incorrects utilisés dans les conditions du flux de conditions	Les opérandes/expressions utilisés d'un ou des deux côtés des opérateurs dans les conditions ne sont pas valides.
Nom d'hôte non valide dans la règle de journalisation des messages	Le nom d'hôte utilisé dans la règle MessageLogging ne peut pas être résolu ou comporte peut-être des caractères spéciaux indésirables.
Nom de KeyValueMap non valide	KeyValueMap n'est pas valide ou est vide dans la règle KeyValueMapOperations du proxy d'API.

Étapes de diagnostic courantes

Utilisez l'API ci-dessous pour obtenir l'état des déploiements correspondant à la révision spécifique du proxy d'API pour laquelle vous observez l'erreur de déploiement:
```
curl -v <management-server-host>:<port#>/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/deployments -u <user>
```

Voici un exemple de sortie de l'API ci-dessus.

"server" : [ { 
"error" : "com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}", 
"status" : "error", 
"type" : [ "message-processor" ], 
"uUID" : "0a20926c-f4bf-401b-af84-05fd84b9f492" 
}, { 
"error" : "com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}", 
"status" : "error", 
"type" : [ "message-processor" ], 
"uUID" : "f2ee6ab4-a108-4465-a7ba-b56530d8e3fc" 
}, { 
"error" : "com.apigee.kernel.exceptions.spi.UncheckedException{ code = application.bootstrap.FailedToConfigure, message = Configuration failed, associated contexts = []}", 
"status" : "error", 
"type" : [ "message-processor" ], 
"uUID" : "0f41991e-b310-4e77-aac5-5fdb150ef9f6" 
},

Le message d'erreur Échec de la configuration apparaît dans chacun des processeurs de messages dans le résultat de l'état du déploiement.
Connectez-vous à l'un des processeurs de messages et consultez le journal /opt/apigee/var/log/edge-message-processor/logs/system.log. Vérifiez s'il y a des erreurs lors du déploiement du proxy d'API.
En fonction de l'erreur ou de l'exception observée dans le journal du processeur de messages, vous devez suivre les étapes de dépannage appropriées et résoudre le problème.
Les sections ci-dessous présentent certaines des exceptions les plus fréquemment observées qui génèrent l'erreur de déploiement Échec de la configuration, et indiquent les étapes à suivre pour résoudre ces problèmes.

Cause: classe Java manquante dans la règle JavaCallout

Diagnostic

Dans les journaux du processeur de messages, si vous voyez une exception indiquant le message Échec de l'instanciation de la classe JavaCallout lors du déploiement d'un proxy d'API (DeployEvent), comme indiqué ci-dessous, passez à l'étape 2. Si ce n'est pas le cas, consultez Opérandes incorrects utilisés dans les conditions du flux de conditions.

Le processeur de messages affiche l'exception suivante lors du déploiement du proxy d'API:

2017-10-10 05:02:42,330 Apigee-Main-5 ERROR MESSAGING.CONFIGURATION - MessageProcessorServiceImpl.configure() : error configuring config events [DeployEvent{organization='myorg', application='oauth2', applicationRevision='14', deploymentSpec=basepath=/;env=dev;, deploymentID=null}] 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to instantiate the JavaCallout Class com.something.apigee.callout.crypto.main.SecretCallout 
at com.apigee.steps.javacallout.JavaCalloutStepDefinition.newInstance(JavaCalloutStepDefinition.java:89) ~[javacallout-1.0.0.jar:na] 
at com.apigee.messaging.runtime.StepDefinition.getStepDefinitionExecution(StepDefinition.java:230) ~[message-processor-1.0.0.jar:na] 
…
<snipped>

Le message d'erreur de l'exception ci-dessus indique que la classe JavaCallout com.something.apigee.callout.crypto.main.SecretCallout n'a pas pu être instanciée. Cette erreur se produit généralement lorsque la classe spécifique n'est pas disponible dans le fichier JAR spécifié dans la règle JavaCallout ou l'un de ses fichiers JAR dépendants.
Vérifiez le fichier JAR contenant toutes les classes associées au package com.something.apigee.callout.crypto.main et vérifiez que la classe spécifique com.something.apigee.callout.crypto.main.SecretCallout était manquante.

Résolution

Ajoutez la classe manquante au fichier JAR spécifique, puis importez le fichier JAR.
Redéployez le proxy d'API.
Dans l'exemple ci-dessus, nous avons résolu le problème en procédant comme suit :
1. Ajouter la classe manquante com.something.apigee.callout.crypto.main.SecretCallout au fichier JAR.
2. Importer le fichier JAR mis à jour et redéployer le proxy d'API

Cause: opérandes incorrects utilisés avec les opérateurs du flux de conditions

Diagnostic

Dans les journaux du processeur de messages, si le message com.apigee.expressions.parser.ParseException s'affiche lors du déploiement d'un proxy d'API ou d'un flux partagé, comme illustré dans les exemples de messages ci-dessous, passez à l'étape 2. Si ce n'est pas le cas, passez à la cause suivante : Invalid Hostname in Message Logging policy (Nom d'hôte non valide dans la règle de journalisation des messages).

Exemple de message d'erreur
```
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
```
Examinons un exemple pour comprendre comment diagnostiquer ce problème.

Exemple : Les opérandes des expressions <Operator> doivent être des expressions de données.

Le processeur de messages affiche l'exception suivante lors du déploiement d'un flux partagé:

2017-11-23 09:11:04,498  Apigee-Main-6 ERROR MESSAGING.RUNTIME - AbstractConfigurator.loadXMLConfigurations() : Unable to Load default for path /organizations/myorg/apiproxies/Introspection/revisions/12/sharedflows/default
2017-11-23 09:11:04,499  Apigee-Main-6 ERROR MESSAGING.RUNTIME - Application.sync() :  sync error for Introspection and revision 12
2017-11-23 09:11:04,499  Apigee-Main-6 ERROR MESSAGING.RUNTIME - Application.sync() :  Actual Error
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
    at com.apigee.expressions.parser.ExpressionParser.buildExpressionTree(ExpressionParser.java:337) ~[expressions-1.0.0.jar:na]
    at com.apigee.expressions.parser.ExpressionParser.parse(ExpressionParser.java:24) ~[expressions-1.0.0.jar:na]
    at com.apigee.expressions.parser.ExpressionParser.parseLogicExpression(ExpressionParser.java:28) ~[expressions-1.0.0.jar:na]
    at com.apigee.messaging.runtime.Step.getExpression(Step.java:67) ~[message-processor-1.0.0.jar:na]
    at com.apigee.messaging.runtime.Step.handleAdd(Step.java:58) ~[message-processor-1.0.0.jar:na]
    at com.apigee.messaging.runtime.SharedFlowRuntime.addStep(SharedFlowRuntime.java:81) ~[message-processor-1.0.0.jar:na] … <snipped>

Le message d'erreur dans l'exception ParseException - "Both the operands for EQUALS expression should be data expressions" indique qu'une condition impliquant un opérateur égal à (=), différent de (!=) ou des statistiques avec (=|) rencontre un problème.

Bien que ce message d'erreur spécifique indique un problème avec l'opérateur **EQUALS**, le même message d'erreur peut s'afficher avec n'importe quel autre opérateur, **or**, **and**, etc.
Examinez les conditions de tous les flux de conditions impliquant l'opérateur spécifique mentionné dans le message d'erreur et vérifiez si l'un des problèmes suivants se présente:
1. Les expressions de chaque côté de l'opérateur sont du même type. Par exemple, si vous avez une variable de chaîne à gauche de l'opérateur, vous devez avoir une autre variable de chaîne ou une autre valeur de chaîne sur le côté droit.
2. Des variables valides sont utilisées entre les opérateurs.
3. Il y a un espace entre l'opérateur et chacune des expressions.
Si le problème se produit dans un proxy d'API, vous devez vérifier les flux de conditions dans les points de terminaison du proxy et cible.
Si l'un des critères ci-dessus n'est pas rempli, vous obtenez l'exception ParseException "Both the operands for EQUALS expression should be data expressions".

Examinons un exemple pour comprendre ce problème. Voici un exemple de condition d'erreur

<Condition>
           (fault.name = "invalid_access_token") or(fault.name = "ApiKeyNotApproved")
</Condition>

Dans cet exemple, vous pouvez observer qu'il n'y a pas d'espace entre l'opérateur "ou" et la condition suivante. Ainsi, lorsque la deuxième condition est analysée, la première expression est considérée comme "or(fault.name" pour l'opérateur EQUALS. Ce nom de variable n'est pas valide. Il n'est donc pas considéré comme une expression de données valide. Vous bénéficiez donc de cette exception:
```
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
```

Résolution

Assurez-vous de toujours disposer d'expressions de données appropriées de chaque côté des opérateurs.
Dans l'exemple décrit ci-dessus, la résolution consistait à s'assurer qu'il y avait de l'espace après l'opérateur "or", comme décrit dans l'extrait de code:
```
<Condition>
           (fault.name = "invalid_access_token") or (fault.name = "ApiKeyNotApproved")
</Condition>
```

Nom d'hôte non valide dans la règle MessageLogging

Diagnostic

Dans les journaux du processeur de messages, si vous voyez une exception avec le message Invalid HostName (Nom d'hôte non valide) lors du déploiement du proxy d'API ou du flux partagé, comme indiqué ci-dessous, passez à l'étape 2. Si ce n'est pas le cas, passez à l'erreur suivante : Invalid KeyValueMap Name (Nom du mappage de valeurs clés non valide).
```
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
```
Examinons ci-dessous deux exemples pour comprendre comment résoudre ce problème.

Exemple 1: Nom d'hôte comportant un caractère spécial indésirable

Le processeur de messages affiche l'exception suivante lors du déploiement du proxy d'API:

  2018-01-20 02:12:13,535 Apigee-Main-3 ERROR MESSAGING.CONFIGURATION - MessageProcessorServiceImpl.configure() : error configuring config events [DeployEvent{organization='myorg', application='providersearch', applicationRevision='4', deploymentSpec=basepath=/;env=prod;, deploymentID=null}] 
  com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler 
  at com.apigee.messaging.runtime.destinations.SyslogDestination.<init>(SyslogDestination.java:44) ~[message-processor-1.0.0.jar:na] 
  at com.apigee.messaging.runtime.destinations.SysLoggerFactory.getInstance(SysLoggerFactory.java:39) ~[message-processor-1.0.0.jar:na]
  at com.apigee.messaging.runtime.destinations.DestinationRegistry.newDestination(DestinationRegistry.java:44) ~[message-processor-1.0.0.jar:na] 
  ...<snipped>

L'exception ci-dessus montre que le déploiement échoue en raison d'un "Nom d'hôte '<nom d'hôte>' non valide pour le gestionnaire Syslog". Cela indique que le nom d'hôte utilisé dans la stratégie MessageLogging est un nom d'hôte non valide.
L'examen de l'exception dans le journal du processeur de messages révèle la présence d'un caractère spécial indésirable "/" à la fin du nom d'hôte 'splunkprod.myorg.com/'..
Ce caractère spécial indésirable était à l'origine de l'erreur de déploiement.

Résolution

Modifiez la stratégie MessageLogging pour supprimer tous les caractères spéciaux indésirables afin de résoudre le problème.
Dans l'exemple ci-dessus, le caractère spécial "/" a été supprimé de la règle MessageLogging. Le problème a été résolu.

Exemple 2: Nom d'hôte impossible à résoudre

Le journal du processeur de messages comportait quelques lignes indiquant que l'événement de déploiement d'un proxy d'API a été déclenché, suivi d'une exception survenue lors du déploiement du proxy d'API:

2017-12-22 00:13:49,057 Apigee-Main-87446 INFO MESSAGING.CONFIGURATION - MessageProcessorServiceImpl.configure() : configuring [DeployEvent{organization='myorg', application='myapi', applicationRevision='42', deploymentSpec=basepath=/;env=dev;, deploymentID=null}] 

2017-12-22 00:13:49,318 Apigee-Main-87446 ERROR c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.refresh() : Unable to resolve host : input-prd.cloud.splunk.com: Name or service not known 

2017-12-22 00:13:49,323 Apigee-Main-87446 ERROR MESSAGING.RUNTIME - AbstractConfigurator.handleUpdate() : Fatal error deploying proxy: {} 
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'input-prd.cloud.splunk.com' for Syslog handler 
at com.apigee.messaging.runtime.destinations.SyslogDestination.<init>(SyslogDestination.java:44) ~[message-processor-1.0.0.jar:na] 
at com.apigee.messaging.runtime.destinations.SysLoggerFactory.getInstance(SysLoggerFactory.java:39) ~[message-processor-1.0.0.jar:na] 
at com.apigee.messaging.runtime.destinations.DestinationRegistry.newDestination(DestinationRegistry.java:44) ~[message-processor-1.0.0.jar:na] 
at com.apigee.steps.messagelogging.MessageLoggingStepDefinition.populateDestinations(MessageLoggingStepDefinition.java:118) ~[message-logging-1.0.0.jar:na] 
at com.apigee.steps.messagelogging.MessageLoggingStepDefinition.handleAdd(MessageLoggingStepDefinition.java:99) ~[message-logging-1.0.0.jar:na] 
…
<snipped>

L'exception ci-dessus montre que le déploiement échoue en raison d'un "Nom d'hôte '<nom d'hôte>' non valide pour le gestionnaire Syslog".
Si vous lisez la ligne au-dessus de l'exception, vous pouvez remarquer que le processeur de messages ne parvient pas à résoudre le nom d'hôte 'input-prd.cloud.splunk.com' fourni dans la règle MessageLogging.

Pour vous en assurer, essayez d'utiliser telnet pour le nom d'hôte et le numéro de port utilisés dans la règle de journalisation des messages.

Vérifiez la stratégie MessageLogging dans la révision spécifique du proxy d'API et vérifiez le nom d'hôte et le numéro de port utilisés. Dans l'exemple ci-dessus, le nom du proxy de l'API est myapi, révision : 42.

Règle MessageLogging

  <MessageLogging async="false" continueOnError="false" enabled="true" name="Log-To-Splunk">
      <DisplayName>Log-To-Splunk</DisplayName>
      <Syslog>
          <Message>Message.id = {request.header.id}</Message>
          <Host>input-prd.cloud.splunk.com</Host>
          <Port>2900</Port>
          <Protocol>TCP</Protocol>
          <SSLInfo>
              <Enabled>true</Enabled>
          </SSLInfo>
      </Syslog>
  </MessageLogging>

Telnet sur l'hôte avec un port spécifique. Dans cet exemple, nous avons essayé telnet et avons obtenu la même erreur que dans le journal du processeur de messages:
```
telnet input-prd.cloud.splunk.com 2900 
telnet: input-prd.cloud.splunk.com: Name or service not known 
input-prd.cloud.splunk.com: Host name lookup failure
```

Cela a clairement prouvé que le nom d'hôte ne peut pas être résolu.

Résolution

Modifiez la stratégie MessageLogging pour utiliser un nom d'hôte valide.

Si le problème persiste, consultez Obtention des informations de diagnostic requis.

Cause: nom de KeyValueMap non valide

Diagnostic

Dans les journaux du processeur de messages, si vous voyez une exception avec le message "KeyValueMap name is invalid" lors du déploiement d'un proxy d'API ou d'un flux partagé, comme indiqué ci-dessous, passez à l'étape 2. Si ce n'est pas le cas, consultez Obtention d'informations de diagnostic.
```
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
```
Étudions un exemple pour comprendre comment dépanner et résoudre ce problème.

Exemple de journal de processeur de messages affichant l'exception avec le message "KeyValueMap name is invalid" (Le nom KeyValueMap est non valide) entraînant une erreur lors du déploiement du proxy d'API

2018-02-27 14:14:50,318  Apigee-Main-6 ERROR MESSAGING.RUNTIME - AbstractConfigurator.handleUpdate() : Fatal error deploying proxy: {}
com.apigee.keyvaluemap.KeyValueMapApiException: KeyValueMap name  is invalid
        at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.validateMapName(KeyValueMapServiceImpl.java:125) ~[keyvaluemap-1.0.0.jar:na]
        at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.createOrUpdateKeyValueMap(KeyValueMapServiceImpl.java:185) ~[keyvaluemap-1.0.0.jar:na]
        at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.digest(KeyValueMapOperationsStepDefinition.java:180) ~[keyvaluemap-operations-1.0.0.jar:na]
        at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.handleAdd(KeyValueMapOperationsStepDefinition.java:197) ~[keyvaluemap-operations-1.0.0.jar:na]
        at com.apigee.entities.AbstractConfigurator.handleUpdate(AbstractConfigurator.java:130) [config-entities-1.0.0.jar:na]
        at com.apigee.messaging.runtime.Application.handleUpdate(Application.java:229) [message-processor-1.0.0.jar:na]

2018-02-27 14:14:50,344  Apigee-Main-6 ERROR BOOTSTRAP - RuntimeConfigurationServiceImpl.dispatchToListeners() : RuntimeConfigurationServiceImpl.dispatchToListeners : Error occurred while dispatching the request DeployEvent{organization='myorg', application='CustomerAPI', applicationRevision='1', deploymentSpec=basepath=/;env=test;, deploymentID=null} to com.apigee.application.bootstrap.listeners.MessageProcessorBootstrapListener@5009d06e
com.apigee.keyvaluemap.KeyValueMapApiException: KeyValueMap name  is invalid
        at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.validateMapName(KeyValueMapServiceImpl.java:125) ~[keyvaluemap-1.0.0.jar:na]
        at com.apigee.keyvaluemap.service.legacy.KeyValueMapServiceImpl.createOrUpdateKeyValueMap(KeyValueMapServiceImpl.java:185) ~[keyvaluemap-1.0.0.jar:na]
        at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.digest(KeyValueMapOperationsStepDefinition.java:180) ~[keyvaluemap-operations-1.0.0.jar:na]
        at com.apigee.steps.keyvaluemapoperations.KeyValueMapOperationsStepDefinition.handleAdd(KeyValueMapOperationsStepDefinition.java:197) ~[keyvaluemap-operations-1.0.0.jar:na]
        at com.apigee.entities.AbstractConfigurator.handleUpdate(AbstractConfigurator.java:130) ~[config-entities-1.0.0.jar:na]
        at com.apigee.messaging.runtime.Application.handleUpdate(Application.java:229) ~[message-processor-1.0.0.jar:na]

La deuxième exception ci-dessus indique que l'erreur de déploiement s'est produite pour API Proxy: CustomerAPI, révision: 1.
En vérifiant la trace de la pile, vous remarquerez qu'une erreur est générée lors de l'exécution de la stratégie KeyValuMapOperations.

En examinant le bundle de proxys d'API, vous constatez qu'il existe une stratégie KeyValuMapOperations contenant le code ci-dessous:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="Pulling-Keys" mapIdentifier="">
 <DisplayName>Pulling Keys</DisplayName>
 <Properties/>
 <ExclusiveCache>false</ExclusiveCache>

Comme indiqué ci-dessus, l'élément mapIdentifier, qui indique le nom du KeyValueMap, comporte une chaîne vide. Le nom KeyValueMap ne peut pas être une chaîne vide. Cette erreur était à l'origine de l'erreur de déploiement.

Résolution

Modifiez la stratégie KeyValueMapOperations afin d'avoir un nom valide pour la KeyValueMap.

Dans l'exemple ci-dessus, nous avons résolu le problème en modifiant les opérations KeyValueMapOperations afin que le nom KeyValueMap soit remplacé par "MyKeyValueMap", comme illustré ci-dessous:

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="Pulling-Keys" mapIdentifier="MyKeyValueMap">
    <DisplayName>Pulling Keys</DisplayName>
    <Properties/>
    <ExclusiveCache>false</ExclusiveCache>

Doit collecter les informations de diagnostic

Si le problème persiste même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et fournissez-lui les informations recueillies.

Résultat de la commande

curl -v <management-server-host>:<port #>/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/deployments -u <user>

Journaux du processeur de messages

/opt/apigee/var/log/edge-message-processor/logs/system.log

Des informations sur les sections de ce playbook qui ont été testées et sur d'autres informations qui nous aideront à accélérer la résolution de ce problème.