Risoluzione dei problemi quando si utilizzano i nodi HTTP e SOAP

Utilizzate i consigli qui riportati per risolvere i problemi più comuni che possono sorgere quando sviluppate flussi di messaggi di servizi Web che contengono nodi HTTP e SOAP.

Informazioni su questa attività

Se si verificano problemi quando si utilizzano i nodi HTTP e SOAP nei flussi di messaggi, completare le istruzioni per i seguenti scenari per diagnosticare e risolvere il problema.

Il messaggio di errore BIP3689 viene emesso quando si distribuisce o si riavvia un server di integrazione
Messaggio di avvertenza BIP3690 emesso quando si distribuisce o si riavvia un server di integrazione
Viene emesso un HandshakeException quando si utilizza un nodo HTTPRequest per effettuare una chiamata a HTTPS

Le risposte alle domande seguenti vi aiuteranno a diagnosticare i problemi con i nodi HTTP o SOAP:

Come si fa a sapere quale ascoltatore stanno usando i nodi HTTP e SOAP?
Come si raccoglie la traccia HTTPListener?

Il messaggio di errore BIP3689 viene emesso quando si distribuisce o si riavvia un server di integrazione

Procedura

Scenario: configurare WS-RM (Web Services Reliable Messaging) su uno o più nodi del flusso di messaggi nella configurazione del flusso di messaggi. Quando si tenta di distribuire la configurazione su un server di integrazione o di riavviare il server di integrazione, viene visualizzato il messaggio di errore BIP3689 .
Spiegazione: Due o più nodi del flusso di messaggi nella configurazione dell'installazione hanno lo stesso valore per la proprietà Path suffix for URL e almeno uno di questi nodi sta usando WS-RM. Non è consentito utilizzare due volte lo stesso URL, poiché un server di integrazione potrebbe ricevere messaggi destinati a un altro server di integrazione, interrompendo così l'ordinamento dei messaggi WS-RM.
Soluzione: Rivedere i valori della proprietà Path suffix for URL nei nodi del flusso di messaggi che si intende distribuire allo stesso nodo di integrazione. Assicurarsi che l'indirizzo URL per un nodo che utilizza WS-RM non sia utilizzato in nessun altro punto della configurazione di distribuzione.

Viene emesso il messaggio di avvertenza BIP3690 quando si distribuisce o si riavvia un server di integrazione

Procedura

Scenario: Il server di integrazione contiene nodi di ingresso SOAP o HTTP in uno o più flussi di messaggi. Quando si tenta di distribuire il server di integrazione o di riavviarlo, viene visualizzato un messaggio di avviso BIP3690 messaggio di avviso.
Spiegazione: questo messaggio di avviso indica che si sta utilizzando lo stesso valore per il suffisso del percorso per la proprietà URL nei nodi SOAP e HTTP nella topologia distribuita. L'avviso non viene visualizzato se si utilizza lo stesso URL in due o più nodi HTTP o in due o più nodi SOAP.
Ad esempio, è possibile distribuire lo stesso flusso a più server di integrazione per motivi di scalabilità e prestazioni; questa configurazione è valida e non attiva l'avvertenza. Tuttavia, l'uso dello stesso URL tra i nodi SOAP e HTTP può causare un comportamento inaspettato e genera sempre un avviso, anche se la configurazione è valida.

Se si stanno utilizzando nodi SOAP e nodi HTTP nei flussi di messaggi su un singolo nodo di integrazione, è possibile scegliere di gestire i messaggi HTTP utilizzando il listener del nodo di integrazione oppure i listener del server di integrazione integrato. Se un ascoltatore nella configurazione riceve messaggi che possono essere ricevuti sia dai nodi SOAPInput che HTTPInput, è necessario controllare attentamente le specifiche di URL in questi nodi. Se entrambe le specifiche URL corrispondono a un messaggio in entrata, il messaggio potrebbe essere ottenuto dal tipo di nodo errato e l'elaborazione potrebbe non riuscire oppure produrre dei risultati imprevisti. Questa situazione si verifica se si specificano valori identici per il suffisso Path per le proprietà URL del nodo HTTPInput e del nodo SOAPInput. Può verificarsi anche se si utilizzano dei caratteri jolly in una delle specifiche, oppure in entrambe, e un messaggio in entrata corrisponde a entrambe le proprietà.
Soluzione: Controllare le specifiche di URL nei nodi di ingresso HTTP e SOAP e verificare che l'instradamento dei messaggi funzioni come previsto.

Viene emesso un HandshakeException quando si utilizza un nodo HTTPRequest per effettuare una chiamata a HTTPS

Procedura

Scenario: stai cercando di effettuare una chiamata HTTPS a un servizio web esterno dal tuo flusso di messaggi IBM® App Connect Enterprise utilizzando un nodo HTTPRequest. Si riceve il seguente errore:

javax.net.ssl.SSLHandshakeException: 
com.ibm.jsse2.util.h: PKIX path building failed:

java.security.cert.CertPathBuilderException: 
PKIXCertPathBuilderImpl could not build a valid CertPath.;

internal cause is: 
java.security.cert.CertPathValidatorException:
The certificate issued by OU=Class 3 Public Primary Certification Authority,
O="VeriSign, Inc.", C=US is not trusted;

internal cause is: 
java.security.cert.CertPathValidatorException: Certificate chaining error

Spiegazione: il nodo di integrazione non può creare l'intero percorso certificato. Il keystore di questo nodo di integrazione deve contenere tutti i certificati in questa catena di autorità di certificazione (CA). Per un nodo di integrazione per verificare la firma digitale su un certificato firmato, il keystore deve contenere la chiave pubblica della CA (Certificate Authority) che ha emesso tale certificato. Se questa chiave pubblica viene emessa su un certificato firmato, il keystore deve contenere la chiave pubblica della CA che ha emesso tale certificato. Questa catena continua fino a quando il nodo di integrazione non raggiunge un'autorità di certificazione root che emette un certificato autofirmato.
Soluzione: verificare di aver aggiunto tutti i certificati richiesti al keystore. Se uno dei componenti nella catena di certificati manca dal keystore, ricreare il keystore utilizzando keytool con l'opzione genkey , quindi reimportare i certificati dell'applicazione.

Come si fa a sapere quale ascoltatore stanno usando i nodi HTTP e SOAP?

Procedura

Scenario: i nodi HTTP e SOAP inclusi in un flusso di messaggi possono utilizzare il listener del nodo di integrazione o il listener incorporato definito nel server di integrazione su cui è distribuito il flusso di messaggi contenitore.
Entrambi gli ascoltatori possono gestire sia i messaggi HTTP che HTTPS, gestendo i diversi tipi di messaggio su porte diverse.
Soluzione: utilizzare il comando mqsireportproperties per verificare le proprietà che definiscono il listener in uso.
1. Verificare se il listener del nodo di integrazione è disabilitato:
```
mqsireportproperties INODE -b httplistener -o HTTPListener -n startListener 
```
  Se questa proprietà è false, tutti i nodi HTTP e SOAP in tutti i server di integrazione utilizzano un ascoltatore incorporato.
2. Se il listener del nodo di integrazione è attivo, è necessario controllare il server di integrazione specifico.
  Per esempio, verificare se l'ascoltatore in integrationServerName viene usato per elaborare i messaggi di HTTP per i nodi HTTP :
```
mqsireportproperties integrationNodeName -e integrationServerName -o ExecutionGroup  -n httpNodesUseEmbeddedListener
```
  Se questa proprietà è true, tutti i nodi HTTP distribuiti su questo server di integrazione utilizzano l'ascoltatore incorporato.
  
  Verificare tutti i server di integrazione per cui si desidera conoscere queste informazioni.
  
  Verificare se l'ascoltatore in integrationServerName sia usato per elaborare i messaggi HTTP per i nodi SOAP:
```
mqsireportproperties integrationNodeName -e integrationServerName -o ExecutionGroup  -n soapNodesUseEmbeddedListener
```
  Se questa proprietà è true (il valore predefinito), tutti i nodi SOAP distribuiti su questo server di integrazione utilizzano il listener integrato.
  
  Verificare tutti i server di integrazione per cui si desidera conoscere queste informazioni.
3. Se entrambe le proprietà sono false, tutti i nodi HTTP e SOAP distribuiti su tutti i server di integrazione utilizzano il listener incorporato. Il valore per la proprietà del server di integrazione viene ignorato.

Risultati

Se si verificano problemi con i flussi di messaggi che contengono nodi HTTP o SOAP e si desidera raccogliere informazioni di tracciamento da fornire al centro di assistenza IBM, tracciare il server di integrazione. Se si utilizza il listener del nodo di integrazione per i nodi HTTP o SOAP, tracciare anche il componente HTTPListener.

Come si raccoglie la traccia HTTPListener?

Informazioni su questa attività

Per raccogliere informazioni sui nodi e sugli ascoltatori di HTTP, è necessario avviare trace, eseguire i flussi di messaggi, quindi recuperare e formattare le informazioni di trace.

Eseguire la traccia del server di integrazione e del componente HTTPListener:

Procedura

Avviare la traccia per il server di integrazione

Ad esempio:

mqsichangetrace INODE -t -e integrationServerName -l debug

Se si sta utilizzando il listener del nodo di integrazione per uno o più server di integrazione, avviare la traccia per il componente HTTPListener in uno dei seguenti due modi:
- Tracciare tutti i componenti del nodo di integrazione eseguendo il comando mqsichangetrace per avviare la traccia con le seguenti opzioni:
```
mqsichangetrace component -t -b -l debug
```
  dove componente è il nome del nodo di integrazione
- Eseguire la traccia solo del componente HTTPListener eseguendo il comando mqsichangeproperties per avviare la traccia con le seguenti opzioni:
```
mqsichangeproperties integrationNodeName -b httplistener -o HTTPListener 
	-n traceLevel -v debug
```

Cosa fare successivamente

Salvare l'output di traccia per poterlo inviare all'Assistenza IBM, se necessario.

Disattivare la traccia una volta terminata la raccolta delle informazioni per evitare di influenzare le prestazioni del nodo di integrazione.