Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione dell'errore di deployment non riuscita

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Sintomo

Il deployment delle revisioni del proxy API o del flusso condiviso tramite l'interfaccia utente perimetrale o l'API di gestione non riesce e viene visualizzato un errore Configurazione non riuscita.

Messaggio di errore

Visualizzerai un messaggio di errore nella UI di Edge, come mostrato di seguito:

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

Ecco lo screenshot di un esempio di messaggio di errore osservato nella UI di Edge:

Possibili cause

Il deployment di un proxy API può non riuscire con l'errore "Configurazione non riuscita" per molti motivi diversi. Nella tabella seguente sono elencate alcune delle cause osservate di frequente che causano questo errore :

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Classe Java mancante nel criterio JavaCallout	Nel file JAR a cui fa riferimento il criterio JavaCallout non è presente una classe Java.	Utenti del cloud privato perimetrale
Operatori errati utilizzati in condizioni nel flusso di condizioni	Gli operandi/espressioni utilizzati su uno o entrambi i lati degli operatori nelle condizioni non sono validi.
Nome host non valido nel criterio di logging dei messaggi	Il nome host utilizzato nel criterio MessageLogging non può essere risolto o potrebbe contenere caratteri speciali indesiderati.
Nome KeyValueMap non valido	Il valore KeyValueMap non è valido o è vuoto nel criterio KeyValueMapOperations nel proxy API.

Passaggi di diagnosi comuni

Ottieni lo stato dei deployment per la revisione specifica del proxy API per cui stai riscontrando l'errore di deployment utilizzando l'API seguente:

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

Di seguito è riportato un output di esempio dell'API riportata sopra:

"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" 
},

Verrà visualizzato il messaggio di errore "Configuration failed" (Configurazione non riuscita) in ciascuno dei processori di messaggi nell'output dello stato del deployment.
Accedi a uno dei processori di messaggi e controlla il log /opt/apigee/var/log/edge-message-processor/logs/system.log. Verifica se si sono verificati errori durante il deployment del proxy API.
A seconda dell'errore o dell'eccezione osservati nel log del processore di messaggi, devi seguire i passaggi di risoluzione dei problemi appropriati e la relativa soluzione.
Le sezioni seguenti forniscono alcune delle eccezioni osservate più di frequente che portano all'errore di deployment "Configurazione non riuscita" e indica i passaggi per risolverle e risolverle.

Causa: classe Java mancante nel criterio JavaCallout

Diagnostica

Se nei log del processore di messaggi noti un'eccezione con il messaggio "Impossibile creare un'istanza della classe JavaCallout" durante il deployment di un proxy API (DeployEvent), come mostrato di seguito, vai al passaggio 2. In caso contrario, vai a Operandi non corretti utilizzati nelle condizioni di Flusso di condizioni.

Il processore di messaggi mostra la seguente eccezione durante il deployment del proxy 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>

Il messaggio di errore nell'eccezione precedente indica che non è stato possibile creare un'istanza della classe JavaCallout com.something.apigee.callout.crypto.main.SecretCallout. Questo errore si verifica in genere quando la classe specifica non è disponibile nel file JAR specificato nel criterio JavaCallout o nei file JAR dipendenti.
Controlla il file JAR che conteneva tutte le classi relative al pacchetto com.something.apigee.callout.crypto.main e conferma che manca la classe specifica com.something.apigee.callout.crypto.main.SecretCallout.

Risoluzione

Aggiungi la classe mancante al file JAR specifico e carica il file JAR.
Esegui di nuovo il deployment del proxy API.
Nell'esempio precedente, abbiamo risolto il problema nel seguente modo:
1. Aggiunta della classe mancante com.something.apigee.callout.crypto.main.SecretCallout al file JAR.
2. Caricamento del file JAR aggiornato e nuova esecuzione del deployment del proxy API.

Causa: operandi errati utilizzati con gli operatori nel flusso di condizioni

Diagnostica

Se nei log del processore di messaggi viene visualizzato com.apigee.expressions.parser.ParseException durante il deployment di un proxy API o di un flusso condiviso, come illustrato nei messaggi di esempio riportati di seguito, vai al passaggio 2. In caso contrario, vai alla causa successiva del criterio Nome host non valido nel logging dei messaggi.

Esempio di messaggio di errore
```
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
```
Diamo un'occhiata a un esempio per capire come diagnosticare questo problema.

Esempio : gli operandi per l'espressione <Operator> devono essere espressioni di dati

Il processore di messaggi mostra la seguente eccezione durante il deployment di un flusso condiviso:

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>

Il messaggio di errore nell'eccezione ParseException - "Both the operands for EQUALS expression should be data expressions" indica che si è verificato un problema con una condizione relativa a uguale a (=), non uguale a (!=) o a statistiche con l'operatore (=|).

Anche se questo particolare messaggio di errore indica un problema con l'operatore **EQUALS**, lo stesso messaggio di errore può essere osservato con qualsiasi altro operatore: **or**, **and**, ecc.
Esamina le condizioni di tutti i flussi di condizioni che coinvolgono l'operatore specifico menzionato nel messaggio di errore e verifica se si verifica uno dei seguenti problemi:
1. Le espressioni ai lati dell'operatore sono dello stesso tipo. Ad esempio, se è presente una variabile stringa sul lato sinistro dell'operatore, devi avere un'altra variabile stringa o un altro valore stringa sul lato destro.
2. Vengono utilizzate variabili valide tra gli operatori.
3. C'è uno spazio tra l'operatore e ciascuna espressione.
Se il problema si verifica in un proxy API, devi verificare i flussi di condizione sia nel proxy che negli endpoint di destinazione.
Se uno qualsiasi dei criteri sopra menzionati non viene soddisfatto, ottieni l'eccezione ParseException - "Both the operands for EQUALS expression should be data expressions".
Diamo un'occhiata a un esempio per comprendere questo problema. Di seguito è riportato un esempio di condizione di errore
```
<Condition>
           (fault.name = "invalid_access_token") or(fault.name = "ApiKeyNotApproved")
</Condition>
```
In questo esempio, puoi osservare che non c'è spazio tra l'operatore "or" e la condizione successiva. Quindi, quando viene analizzata la seconda condizione, la prima espressione viene considerata come "or(fault.name") per l'operatore EQUALS. Questo non è un nome di variabile valido, quindi non viene considerato come un'espressione di dati valida. Di conseguenza si ottiene questa eccezione:
```
com.apigee.expressions.parser.ParseException: Both the operands for EQUALS expression should be data expressions
```

Risoluzione

Assicurati di avere sempre espressioni dati corrette su entrambi i lati degli operatori.
Nell'esempio sopra illustrato, la soluzione consisteva nel garantire che ci fosse spazio dopo l'operatore "or", come descritto nello snippet di codice:
```
<Condition>
           (fault.name = "invalid_access_token") or (fault.name = "ApiKeyNotApproved")
</Condition>
```

Nome host non valido nelle norme di MessageLogging

Diagnostica

Se nei log del processore di messaggi noti un'eccezione con il messaggio "Nome host non valido" durante il deployment del proxy API o del flusso condiviso, come illustrato di seguito, vai al passaggio 2. In caso contrario, vai alla causa successiva Nome KeyValueMap non valido.
```
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
```
Di seguito sono riportati due esempi per capire come risolvere questo problema.

Esempio 1: HostName contiene un carattere speciale indesiderato

Il processore di messaggi mostra la seguente eccezione durante il deployment del proxy 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'eccezione precedente mostra che il deployment non è riuscito a causa di "Nome host non valido '<nomehost>' per gestore Syslog". Indica che il nome host utilizzato nel criterio MessageLogging non è valido.
Un esame attento dell'eccezione nel log dell'Elaboratore dei messaggi mostra la presenza di un carattere speciale indesiderato "/" alla fine di HostName 'splunkprod.myorg.com/'..
Questo carattere speciale indesiderato era la causa dell'errore di deployment.

Risoluzione

Per risolvere il problema, modifica il criterio di MessageLogging per rimuovere eventuali caratteri speciali indesiderati.
Nell'esempio precedente, il carattere speciale "/" è stato rimosso dalle norme di MessageLogging. Il problema è stato risolto.

Esempio 2: nome host non risolvibile

Il log del processore di messaggi conteneva poche righe che indicano l'attivazione dell'evento di deployment per un proxy API seguito da un'eccezione che si verifica durante il deployment del proxy 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'eccezione precedente mostra che il deployment non è riuscito a causa di "Nome host non valido '<nomehost>' per gestore Syslog".
Se leggi la riga sopra l'eccezione, puoi notare che il Processore di messaggi non è in grado di risolvere il nome host 'input-prd.cloud.splunk.com' fornito nel criterio MessageLogging.

Per verificare, puoi provare a utilizzare Telnet con il nome host e il numero di porta utilizzati nel criterio di logging dei messaggi.

Controlla il criterio MessageLogging nella revisione specifica del proxy API e verifica il nome host e il numero di porta utilizzati. Nell'esempio precedente, il nome del proxy API: myapi, revisione: 42.

Criterio 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 all'host con una porta specifica. Per questo esempio, abbiamo provato telnet e abbiamo ricevuto lo stesso errore indicato nel log del processore di messaggi:
```
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
```

Questo dimostra chiaramente che il nome host non può essere risolto.

Risoluzione

Modifica il criterio di MessageLogging in modo che utilizzi un nome host valido.

Se il problema persiste, vai alla pagina Devi raccogliere informazioni diagnostiche.

Causa: nome mappa valore non valido

Diagnostica

Se nei log del processore di messaggi vedi un'eccezione con il messaggio "KeyValueMap name is invalid" durante il deployment di un proxy API o di un flusso condiviso come mostrato di seguito, vai al passaggio 2. In caso contrario, vai a Raccogliere informazioni diagnostiche.
```
com.apigee.rest.framework.ValidationException: Invalid syslog config: Invalid HostName 'splunkprod.myorg.com/' for Syslog handler
```
Esaminiamo un esempio per capire come risolvere questo problema.

Log del processore di messaggi di esempio che mostra l'eccezione con il messaggio "Nome KeyValueMap non valido" che genera un errore durante il deployment del proxy 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 seconda eccezione sopra indicata indica che si è verificato l'errore di deployment per proxy API: API Customer, revisione: 1.
Controllando la traccia dello stack, puoi notare che viene generato un errore durante l'esecuzione del criterio KeyValuMapOperations.

Esaminando il bundle del proxy API, noterai che è presente un criterio KeyValuMapOperations con il codice riportato di seguito:

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

Come visto sopra, mapIdentifier, che indica il nome della KeyValueMap, ha una stringa vuota. La stringa del nome KeyValueMap non può essere vuota. Questa era la causa dell'errore di deployment.

Risoluzione

Modifica il criterio KeyValueMapOperations in modo che abbia un nome valido e corretto per la KeyValueMap.

Nell'esempio precedente, abbiamo risolto il problema modificando il valore KeyValueMapOperations in modo che il nome KeyValueMap fosse "MyKeyValueMap" come mostrato di seguito:

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

Raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contatta l'assistenza Apigee Edge e fornisci le informazioni raccolte.

Output del comando

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

Log del processore di messaggi

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

Dettagli sulle sezioni di questa guida pratica messe a punto e altri approfondimenti che ci aiuteranno a risolvere il problema in modo rapido.