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

Échec de la configuration des erreurs de déploiement

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

Le déploiement du proxy d'API ou des révisions 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 recevrez 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 avec le message "Échec de la configuration" pour diverses raisons. Le tableau ci-dessous répertorie quelques causes fréquemment observées à l'origine de 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 JavaAccroche.	Utilisateurs du cloud privé Edge
Opérandes incorrects utilisés dans les conditions du flux de condition	Les opérandes/expressions utilisés d'un côté 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 peut contenir des caractères spéciaux indésirables.
Nom KeyValueMap non valide	KeyValueMap n'est pas valide ou est vide dans la règle KeyValueMapOperations du proxy d'API.

Étapes de diagnostic courantes

Obtenez l'état des déploiements pour la révision spécifique du proxy d'API pour lequel vous observez l'erreur de déploiement à l'aide de l'API ci-dessous:
```
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 "Configuration failed" (Échec de la configuration) s'affichera 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 si des erreurs se sont produites 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 entraînent l'erreur de déploiement Échec de la configuration, et expliquent comment les résoudre et les résoudre.

Cause: classe Java manquante dans la règle JavaCallout

Diagnostic

Dans les journaux du processeur de messages, si vous voyez une exception avec le message "Failed to appeal the Java Vérifiez Class" 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 condition.

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 dans l'exception ci-dessus indique que la classe JavaAccroche 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 JavaAccroche ou dans l'un de ses fichiers JAR dépendants.
Vérifiez le fichier JAR qui contenait toutes les classes relatives au package com.something.apigee.callout.crypto.main et confirmez que la classe spécifique com.something.apigee.callout.crypto.main.SecretCallout était manquante.

Solution

Ajoutez la classe manquante au fichier JAR spécifique, puis importez-le.
Redéployez le proxy d'API.
Dans l'exemple ci-dessus, nous avons résolu le problème en: <ph type="x-smartling-placeholder">
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 des opérateurs dans le flux de condition

Diagnostic

Dans les journaux du processeur de messages, si vous voyez un com.apigee.expressions.parser.ParseException lors du déploiement d'un proxy d'API ou d'un flux partagé, comme indiqué dans les exemples de messages ci-dessous, passez à l'étape 2. Si ce n'est pas le cas, passez à la cause suivante, 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 : Opérandes pour <Operator> doit ê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 ParseException - "Both the operands for EQUALS expression should be data expressions" indique qu'une condition impliquant égal à (=), non égal à (!=) ou des statistiques avec l'opérateur (=|) présente un problème.

Bien que ce message d'erreur indique un problème avec l'opérateur **EQUALS**, le même message d'erreur peut être observé avec n'importe quel autre opérateur (**ou**, **and**, etc.).
Examinez les conditions de tous les flux de condition impliquant l'opérateur spécifique mentionné dans le message d'erreur et vérifiez s'il existe l'un des problèmes suivants:
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 disposer d'une autre variable de chaîne ou valeur de chaîne à droite.
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 condition dans les points de terminaison du proxy et cibles.
Si l'un des critères mentionnés 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 le « ou » puis la condition suivante. Ainsi, lorsque la deuxième condition est en cours d'analyse, 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 traité comme une expression de données valide. Par conséquent, vous obtenez l'exception suivante:
```
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
```

Solution

Assurez-vous de toujours disposer d'expressions de données appropriées de chaque côté des opérateurs.
Dans l'exemple discuté ci-dessus, la résolution consistait à s'assurer qu'il y avait un espace après le « ou » 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" pendant le 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 à la cause suivante Nom KeyValueMap non valide.
```
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
```
Examinons les deux exemples ci-dessous pour comprendre comment résoudre ce problème.

Exemple 1: HostName comporte 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 de l'erreur "Invalid HostName '<hostname>" (Nom d'hôte non valide '<nom d'hôte>) pour le gestionnaire Syslog". Cela indique que le nom d'hôte utilisé dans la règle MessageLogging est un nom d'hôte non valide.
Un examen attentif de l'exception dans le journal du processeur de messages montre la présence d'un caractère spécial indésirable "/" à la fin de HostName 'splunkprod.myorg.com/'.
Ce caractère spécial indésirable était à l'origine de l'erreur de déploiement.

Solution

Modifiez la règle 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 qui indiquent que l'événement de déploiement d'un proxy d'API est déclenché, suivi d'une exception qui se produit pendant le 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 de l'erreur "Invalid HostName '<hostname>" (Nom d'hôte non valide '<nom d'hôte>) pour le gestionnaire Syslog".
Si vous lisez la ligne au-dessus de l'exception, vous remarquerez 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, vous pouvez essayer d'utiliser la commande Telnet avec le nom d'hôte et le numéro de port utilisés dans la règle de journalisation des messages.

Vérifiez la règle 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 d'API: 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>

Utilisez Telnet vers l'hôte avec un port spécifique. Dans cet exemple, nous avons essayé telnet et 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.

Solution

Modifiez la règle MessageLogging pour utiliser le nom d'hôte valide.

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

Cause: nom 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 Doit collecter des informations de diagnostic.
```
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
```
Examinons un exemple pour comprendre comment dépanner et résoudre ce problème.

Exemple de journal du processeur de messages affichant l'exception avec le message "KeyValueMap name is invalid" (Le nom KeyValueMap n'est pas 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 le proxy d'API: CustomerAPI, révision: 1.
En consultant la trace de la pile, vous pouvez constater qu'une erreur est générée lors de l'exécution de la règle KeyValuMapOperations.

En examinant le bundle de proxys d'API, vous constatez qu'il existe une règle KeyValuMapOperations dont le code est le suivant:

<?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 nous l'avons vu ci-dessus, l'élément mapIdentifier, qui indique le nom de la KeyValueMap, comporte une chaîne vide. Le nom KeyValueMap ne peut pas être une chaîne vide. C'est la cause de l'erreur de déploiement.

Solution

Modifiez la règle KeyValueMapOperations afin d'attribuer un nom valide et correct au KeyValueMap.

Dans l'exemple ci-dessus, nous avons résolu le problème en modifiant le champ KeyValueMapOperations pour lui attribuer le nom "MyKeyValueMap" pour KeyValueMap. comme indiqué 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>

Nécessité de collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et fournissez-lui les informations collectées.

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 de processeur de messages

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

Des informations sur les sections de ce playbook qui ont fait l'objet de tests et toute autre information susceptible de nous aider à résoudre rapidement le problème