Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Échec de la configuration des erreurs de déploiement

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

Problème constaté

Le déploiement des révisions de proxy d'API ou de flux partagé via l'UI Edge ou l'API de gestion échoue avec une erreur Configuration failed (Échec de la configuration).

Message d'erreur

Un message d'erreur s'affiche dans l'UI 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'UI Edge :

Causes possibles :

Le déploiement d'un proxy d'API peut échouer avec l'erreur "Configuration failed" (Échec de la configuration) pour de nombreuses raisons différentes. Le tableau ci-dessous répertorie quelques causes fréquemment observées qui entraînent cette erreur :

Cause	Description	Instructions de dépannage applicables
Classe Java manquante dans la règle JavaCallout	Une classe Java est manquante dans le fichier JAR référencé par la règle JavaCallout.	Utilisateurs de Cloud privé Edge
Opérandes incorrects utilisés dans les conditions du flux de conditions	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	Le 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 laquelle 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 résultat 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'affiche dans chacun des processeurs de messages de la sortie de l'état de 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/exception observée dans le journal du processeur de messages, vous devez suivre les étapes de dépannage et de résolution appropriées pour le problème.
Les sections ci-dessous fournissent certaines des exceptions les plus fréquemment observées qui entraînent l'erreur de déploiement "Configuration failed" (Échec de la configuration), ainsi que les étapes à suivre pour les dépanner 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 instantiate the JavaCallout Class" (É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. Sinon, passez à la section 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 dans l'un de ses fichiers JAR dépendants.
Vérifiez le fichier JAR qui contenait toutes les classes appartenant 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 et importez le fichier JAR.
Redéployez le proxy d'API.
Dans l'exemple ci-dessus, nous avons résolu le problème en :
1. ajoutant la classe manquante com.something.apigee.callout.crypto.main.SecretCallout au fichier JAR ;
2. important le fichier JAR mis à jour et en redéployant le proxy d'API.

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

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. Sinon, 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 : les opérandes de l'expression <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 ParseException - "Both the operands for EQUALS expression should be data expressions" indique qu'il existe un problème avec une condition impliquant l'opérateur égal à (=), différent de (!=) ou Stats avec (=|).

Bien que ce message d'erreur spécifique 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 : **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 produit :
1. Les expressions de part et d'autre 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 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 conditions dans les points de terminaison du proxy et les points de terminaison 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" (Les deux opérandes de l'expression EQUALS doivent être des expressions de données).

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 constater qu'il n'y a pas d'espace entre l'opérateur "or" 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. Il ne s'agit pas d'un nom de variable valide. Il n'est donc pas traité comme une expression de données valide. Par conséquent, vous obtenez cette exception :
```
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
```

Solution

Assurez-vous de toujours avoir des expressions de données appropriées de part et d'autre des opérateurs.
Dans l'exemple ci-dessus, la solution consistait à s'assurer qu'il y avait un 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 d'un proxy d'API ou d'un flux partagé, comme indiqué ci-dessous, passez à l'étape 2. Sinon, 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 dépanner et résoudre ce problème.

Exemple 1 : nom d'hôte contenant 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 indique que le déploiement échoue en raison de "Invalid HostName '<hostname>' for Syslog handler" (Nom d'hôte non valide '<hostname>' pour le gestionnaire Syslog). Cela indique que le nom d'hôte utilisé dans la règle MessageLogging n'est pas valide.
L'examen attentif de l'exception dans le journal du processeur de messages montre qu'il existe 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.

Solution

Modifiez la règle MessageLogging pour supprimer 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 ainsi été résolu.

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

Le journal du processeur de messages contenait quelques lignes indiquant que l'événement de déploiement d'un proxy d'API était déclenché, suivi d'une exception qui se produit 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 indique que le déploiement échoue en raison de "Invalid HostName '<hostname>' for Syslog handler" (Nom d'hôte non valide '<hostname>' pour le gestionnaire Syslog).
Si vous lisez la ligne au-dessus de l'exception, vous pouvez constater 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 confirmer cela, vous pouvez essayer de vous connecter à l'aide de Telnet au nom d'hôte et au numéro de port utilisés dans la règle de journalisation des messages.
1. 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 est "myapi" et la révision est "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>
```
2. Connectez-vous à l'hôte avec un port spécifique. Dans cet exemple, nous avons essayé Telnet et obtenu la même erreur que celle observée 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 prouve clairement 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 la page Vous devez 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" (Le nom KeyValueMap n'est pas valide) lors du déploiement d'un proxy d'API ou d'un flux partagé, comme indiqué ci-dessous, passez à l'étape 2. Sinon, consultez la page Vous devez 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 API Proxy : CustomerAPI, révision : 1.
En vérifiant la trace de la pile, vous pouvez constater que l'erreur est générée lors de l'exécution de la règle KeyValuMapOperations.

En examinant le bundle du proxy d'API, vous constatez qu'il existe une règle KeyValuMapOperations dont le code est indiqué 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 vous pouvez le voir ci-dessus, le mapIdentifier, qui indique le nom du KeyValueMap, contient 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 pour que le KeyValueMap ait un nom valide approprié.

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

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, veuillez collecter 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 du processeur de messages

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

Informations sur les sections de ce guide qui ont été essayées et toute autre information qui nous aidera à accélérer la résolution de ce problème.