Risoluzione di problemi di implementazione che insorgono durante lo sviluppo dei flussi di messaggi

Utilizzare i consigli forniti qui come supporto nella risoluzione di alcuni problemi comuni che possono insorgere durante l'esecuzione di flussi di messaggi.

Informazioni su questa attività

Indirizzamento messaggi al terminale failure di un nodo MQInput
Mancata uscita dei messaggi immessi nel flusso di messaggi
Il proprio server di integrazione non sta leggendo i messaggi dalle code di immissione
Il server di integrazione termina durante l'elaborazione dei messaggi
Il server di integrazione si blocca o termina con un core dump
Il nodo XSLTransform non funziona dopo la distribuzione e vengono emessi degli errori che indicano che non è stato possibile elaborare il foglio di stile
Mancato invio dei messaggi di output alle destinazioni previste
Problemi nell'invio di un messaggio ad un URL del nodo HTTP
Quando si utilizzano le connessioni sicure HTTP, si modifica la destinazione di un host DNS ma il nodo di integrazione utilizza una definizione di host DNS memorizzata nella cache
Il nodo TimeoutControl emette il messaggio di errore BIP4606 o BIP4607 quando l'ora di inizio della richiesta di timeout che riceve è nel passato
Si sta utilizzando un nodo TimeoutControl con un nodo TimeoutNotification , con più client in esecuzione contemporaneamente e i messaggi sembrano essere eliminati
Il messaggio di errore BIP5347 viene emesso su AIX quando si esegue un flusso di messaggi che utilizza una serie di messaggi
Messaggio di errore BIP2130 viene emesso con il valore della code page di -1 O -2
Il server di integrazione viene riavviato prima che un nodo MQGet abbia richiamato tutti i messaggi

I messaggi vengono indirizzati al terminale Failure di un nodo MQInput

Procedura

Scenario I messaggi ricevuti in un flusso di messaggi vengono indirizzati immediatamente al terminale Failure sul nodo MQInput (se è connesso) o ne viene eseguito il rollback.
Spiegazione: quando IBM® MQ riceve un messaggio, viene segnalato un errore se tutte le seguenti condizioni sono vere:
- Il nodo MQInput richiede la conversione del contenuto del messaggio (la proprietà Converti è impostata su yes sul nodo).
- Il messaggio si compone solamente di un MQMD seguito dal contenuto del messaggio.
- Il formato del messaggio, come specificato in MQMD, è impostato su MQFMT_NONE.
Questo errore fa sì che il messaggio venga indirizzato al terminale Failure.
Soluzione: in generale, non è necessario richiedere l'uso dell'opzione ` IBM MQ ` per convertire il contenuto del messaggio, poiché il nodo di integrazione elabora i messaggi in tutte le tabelle di codici e le codifiche supportate da IBM MQ. Impostare la proprietà Converti in no per garantire che i messaggi fluiscano dal nodo MQInput ai nodi successivi nel flusso di messaggi.

Mancata uscita dei messaggi immessi nel flusso di messaggi

Procedura

Scenario: sono stati inviati messaggi nel flusso di messaggi e sono stati rimossi dalla coda di input, ma non viene visualizzato nulla all'altra estremità del flusso di messaggi.
Spiegazione: è possibile che si verifichi questo errore in diverse situazioni. Prendere in considerazione gli scenari seguenti finché non si riesce a identificare la situazione che provoca l'errore:
1. Controlla il flusso dei messaggi nel Toolkit " IBM App Connect Enterprise ".
  È possibile che il terminale Failure del nodo MQInput sia stato connesso a un nodo successivo invece che al terminale Out. Il terminale Out è quello centrale rispetto agli altri tre. I messaggi diretti a un terminale Out non collegato vengono eliminati.
2. Se il terminale di output del nodo MQInput è connesso correttamente a un nodo successivo, controllare il log degli errori locale del nodo di integrazione per un'indicazione che l'elaborazione del messaggio è stata terminata a causa di problemi. Ulteriori messaggi forniscono informazioni più dettagliate.
  Se il terminale di errore del nodo MQInput è stato connesso (ad esempio, a un nodo MQOutput ), questi messaggi non vengono visualizzati.
  
  Il collegamento di un nodo a un terminale Failure di un altro nodo indica che il flusso di messaggi è stato preposto alla gestione di tutta l'elaborazione errori. Se si connette un terminale Failure a un nodo MQOutput , il flusso di messaggi ignora tutti gli errori che si verificano.
3. Se il terminale Out del nodo MQInput è connesso correttamente a un nodo successivo e il log degli errori locale non contiene messaggi di errore, attivare la traccia utente per il flusso di messaggi:
  Questa azione produce una voce di traccia utente solo dai nodi che vengono visitati dal messaggio.
  
  Sui sistemi distribuiti, è possibile richiamare le voci di traccia utilizzando il comando mqsichangetrace e visualizzare i record per controllare il percorso del messaggio nel flusso di messaggi.
4. Se la traccia utente mostra che il messaggio non sta effettuando il percorso previsto attraverso il flusso di messaggi, aumentare il livello di traccia utente in Debug selezionando il flusso di messaggi, facendo clic con il pulsante destro del mouse su di esso e facendo clic su Traccia utente > Debug.
  Inviare nuovamente il messaggio nel flusso di messaggi. La traccia a livello di debug produce maggiori informazioni dettagliate sul perché il messaggio venga instradando in tale direzione ed è possibile determinare i motivi delle azioni intraprese dal flusso di messaggi.
  
  Una volta risolto il problema, non dimenticare di disattivare la traccia, altrimenti potrebbe esserci una ripercussione sulle prestazioni.
5. Se il comando MQPUT sulla coda di output definita sul nodo MQOutput non ha esito positivo (ad esempio, la coda è piena o put è disabilitato), la destinazione finale di un messaggio dipende da:
  - Se il terminale Failure del nodo MQOutput è connesso.
  - Indica se il messaggio viene elaborato in modo transazionale (a sua volta, ciò dipende dall'impostazione della modalità di transazione del nodo MQInput , del nodo MQOutput e delle code di input e di output).
  - Se il messaggio è permanente o temporaneo. Quando la modalità transazione è impostata sul valore predefinito Automatica, la transazionalità del messaggio deriva dal modo in cui è stata specificata nel nodo di input. Tutti i messaggi vengono gestiti come permanenti se la modalità transazione=sì e come temporanei se modalità transazione=no.
  In genere, se un percorso non è definito per un errore (ossia, non è connesso né il terminale Catch né il terminale Failure del nodo MQInput ):
  - Vengono eliminati i messaggi non permanenti.
  - Viene eseguito il rollback dei messaggi transazionali sulla coda di input per riprovare:
    
    Se il conteggio di backout del messaggio è inferiore alla soglia di backout (BOTHRESH) della coda di input, il messaggio viene nuovamente richiamato e inviato al terminale Out.
    
    Quando il conteggio di backout equivale o supera la soglia di backout, potrebbe verificarsi una delle seguenti situazioni:
    
    Il messaggio viene inserito nella coda di backout, se ne viene specificata una (utilizzando l'attributo BOQNAME della coda di input).
    
    Il messaggio viene inserito nella coda di messaggi non recapitati, in assenza di una coda di backout o in caso di errore di MQPUT nella coda di backout.
    
    Se l'operazione MQPUT sulla coda di messaggi non consegnati ha esito negativo oppure non è stata definita alcuna coda di tale tipo, il flusso di messaggi esegue un loop continuo tentando di inserire il messaggio sulla coda di messaggi non consegnati.
  - Se per il terminale failure è definito un percorso, tale percorso indica la destinazione del messaggio. Se entrambi i terminali Catch e Failure sono collegati, il messaggio viene distribuito attraverso il terminale Catch.
6. Se il flusso di messaggi utilizza la modalità transazione=yes nelle proprietà del nodo MQInput e i messaggi non vengono visualizzati in una coda di output, controllare il percorso del flusso di messaggi.
  - Se il flusso di messaggi presenta percorsi corretti (ma che non terminano in una coda di output):
    
    Non si è verificato alcun errore nel flusso di messaggi ed il messaggio non viene sottoposto a backout.
    
    Il flusso di messaggi viene inserito in una destinazione alternativa (ad esempio il terminale Catch, la coda di messaggi non recapitati o la coda di backout della coda).
  - Controllare che tutti i percorsi possibili raggiungano un nodo di output finale e non raggiungano un'estremità inattiva. Ad esempio, controllare che:
    
    Il terminale Unknown di un nodo Filter è stato collegato ad un altro nodo nel flusso di messaggi.
    
    Sono stati connessi i terminali True e False di un nodo Filter a un altro nodo nel flusso di messaggi.

Il server di integrazione non sta leggendo i messaggi dalle code di input

Procedura

Scenario Il server di integrazione è stato avviato, ma non sta leggendo i messaggi dalle code di input specificate.
Spiegazione: un server di integrazione avviato potrebbe non leggere i messaggi dalle code di input dei flussi di messaggi perché gli errori precedenti potrebbero aver lasciato il gestore code in uno stato incongruente.
Soluzione: completare la seguente procedura:
1. Arrestare il nodo di integrazione
2. Interrompi l'ascolto di " IBM MQ ".
3. Interrompi il processo che ha avviato il canale " IBM MQ ".
4. Arrestare il gestore delle code di IBM MQ.
5. Riavvia il gestore delle code di IBM MQ.
6. Riavvia il programma di avvio del canale IBM MQ.
7. Riavvia il listener di IBM MQ.
8. Riavviare il nodo di integrazione.

Il server di integrazione termina durante l'elaborazione dei messaggi

Informazioni su questa attività

Procedura

Scenario: Durante l'elaborazione di una serie di messaggi, il server di integrazione (DataFlowEngine ) le dimensioni del processo crescono costantemente senza stabilizzarsi.
Questa situazione potrebbe causare la fine del processo DataFlowEngine se non riesce ad assegnare più memoria e a eseguire il riavvio. Potrebbe essere registrato il messaggio di errore BIP2106 che indica una condizione di mancanza di memoria.
Inoltre, se si utilizza Db2® su sistemi distribuiti, si potrebbe ricevere il messaggio:
```
SQL0954C  Not enough storage is  available in the application heap to process 
the statement.
```
Spiegazione: quando viene effettuata una chiamata al database dall'interno di un nodo del flusso di messaggi, il flusso crea l'SQL appropriato, che viene inviato utilizzando ODBC al gestore database. Come parte di questo processo, l'istruzione SQL è preparata utilizzando la funzione SQLPrepare e un handle di istruzione viene acquisito in modo che l'istruzione SQL possa essere eseguita.
Ai fini delle prestazioni, una volta preparata l'istruzione, questa e l'handle vengono salvati in una cache per ridurre il numero di chiamate alla funzione SQLPrepare. Se l'istruzione è già nella cache, l'handle di istruzione viene restituito in modo che possa essere eseguito nuovamente con parametri appena associati.

La stringa dell'istruzione viene utilizzata per eseguire la ricerca della cache. Utilizzando stringhe SQL protette che differiscono leggermente per ciascun messaggio, l'istruzione non viene trovata nella cache e viene eseguita sempre una funzione SQLPrepare (e viene aperto un nuovo cursore ODBC). Quando si utilizzano istruzioni PASSTHRU, utilizzare indicatori di parametri in modo che la stessa istruzione SQL preparata possa essere utilizzata per ciascun messaggio elaborato, con i parametri associati in fase di runtime. Questo metodo è più efficace in termini di risorse di database e, per istruzioni che vengono eseguite ripetutamente, risulta più veloce.

Tuttavia, non è sempre possibile utilizzare indicatori di parametri oppure si potrebbe voler creare dinamicamente le stringhe di istruzioni SQL in fase di runtime. Questa situazione conduce potenzialmente all'inserimento nella cache di molte istruzioni SQL univoche. La cache stessa non aumenta molto in quanto tali istruzioni non sono generalmente grandi, ma diverse piccole assegnazioni di memoria possono produrre la frammentazione della memoria.
Soluzione: se si verificano questi tipi di situazioni, disabilitare la cache delle istruzioni preparate impostando la variabile di ambiente MQSI_EMPTY_DB_CACHE su un valore arbitrario. Quando questa variabile di ambiente viene creata, le istruzioni preparate per tale flusso di messaggi vengono vuotate alla fine dell'elaborazione di ciascun messaggio. Questa azione potrebbe causare un lieve peggioramento delle prestazioni in quanto ogni istruzione SQL viene preparata.

Il server di integrazione si blocca o termina con un core dump

Procedura

Scenario : durante l'elaborazione di un messaggio, un server di integrazione si blocca con un elevato utilizzo di CPU o termina con un core dump. La traccia di stack derivante dal file abend o core dump è di grandi dimensioni e mostra diverse chiamate sullo stack. I messaggi scritti nel log di sistema potrebbero indicare condizioni di "mancanza di memoria" o di "errata assegnazione". Le caratteristiche del flusso di messaggi in tale scenario includono spesso un loop hard-wired su alcuni nodi.
Spiegazione: quando un thread del flusso di messaggi viene eseguito, richiede memoria per eseguire le istruzioni definite dalla logica dei suoi nodi connessi. Questa memoria proviene dalla memoria heap e stack del server di integrazione. L'esecuzione di un flusso di messaggi è limitata dalla dimensione dello stack, il cui valore predefinito varia a seconda del sistema operativo.
Soluzione: se è necessario un flusso di messaggi maggiore della dimensione dello stack, è possibile aumentare il limite della dimensione dello stack e riavviare i nodi di integrazione in esecuzione nel sistema in modo che utilizzino il nuovo valore.
Per informazioni sull'impostazione della dimensione dello stack per il proprio sistema operativo, consultare Risorse di sistema per lo sviluppo del flusso di messaggi.

Il nodo XSLTransform non funziona dopo la distribuzione e vengono emessi degli errori che indicano che non è stato possibile elaborare il foglio di stile

Procedura

Scenario: il proprio nodo XSLTransform non funziona dopo la distribuzione delle risorse e vengono visualizzati degli errori che indicano che non è stato possibile elaborare il foglio di stile.
Soluzione:
- Se il nodo di integrazione non è in grado di trovare il foglio di stile o i file XML richiesti, migrare i fogli di stile o i file XML con riferimenti di percorso relativi.
- Se il contenuto di un foglio di stile o di un file XML è danneggiato e quindi non più utilizzabile (ad esempio, se durante una distribuzione si verifica il malfunzionamento di un file system), ridistribuire il foglio di stile o il file XML danneggiato.

Mancato invio dei messaggi di output alle destinazioni previste

Procedura

Scenario : è stato sviluppato un flusso di messaggi che crea un elenco di destinazioni nella struttura ad albero LocalEnvironment . L'elenco potrebbe contenere code per MQOutput nodo, etichette per a RouteToLabel nodo o URL per un file Richiesta HTTP nodo. Tuttavia, i messaggi non raggiungono tali destinazioni, ma non sono presenti messaggi di errore.
Soluzione:
- Accertarsi di aver impostato la modalità di calcolo su un valore che include LocalEnvironment nel messaggio di output; ad esempio, Tutto. L'impostazione predefinita della modalità di calcolo è Messaggio, e tutte le modifiche apportate a LocalEnvironment vengono perse.
- Verificare le istruzioni ESQL. Il contenuto e la struttura di LocalEnvironment non sono imposti, l'editor ESQL (e content assist) non fornisce quindi alcun supporto per i riferimenti di campo e potrebbe essere stato specificato uno o più di questi riferimenti in modo non corretto.
  Alcune procedure di esempio che consentono di impostare gli elenchi di destinazioni vengono fornite in Inserimento destinazione nella struttura ad albero dell'ambiente locale. È possibile utilizzare direttamente tali procedure oppure modificarle in base ai propri requisiti.

Problemi nell'invio di un messaggio ad un URL del nodo HTTP

Procedura

Scenario: L'invio di un messaggio al nodo HTTP URL causa un timeout, oppure il messaggio non viene inviato al flusso di messaggi corretto.
Spiegazione: Le seguenti regole sono vere quando viene eseguita la corrispondenza URL :
- Esiste una corrispondenza uno-a-uno tra le richieste di HTTP e i nodi HTTPInput. Per ciascuna richiesta HTTP, solo un flusso di messaggi riceve il messaggio. Questa istruzione è true anche se due flussi di messaggi sono in ascolto sullo stesso URL. Allo stesso modo, non è possibile prevedere quale nodo MQInput in ascolto su una particolare coda riceverà un messaggio.
- I messaggi vengono inviati a URL wildcard solo se non è presente alcun altro URL corrispondente. Quindi, un URL di /* riceve tutti messaggi che non corrispondono a un altro URL.
- La modifica di URL in un nodo HTTPInput non rimuove automaticamente la voce dall'ascoltatore HTTP. Ad esempio, se un URL /A viene usato e poi modificato in un URL di /B, l'URL di /A viene ancora utilizzato per ascoltare anche se non esiste alcun flusso di messaggi per elaborare il messaggio. Questo URL errato viene rimosso dopo che il nodo di integrazione è stato arrestato e riavviato due volte.
Soluzione: Per sapere su quale URL il nodo di integrazione è attualmente in ascolto, si può consultare il file wsplugin6.conf nel seguente percorso:
- Su Linux® e UNIX: /var/mqsi/components/integrationNodeName/config
- In Windows, %ProgramData%\IBM\MQSI\components\integrationNodeName\config, dove %PROGRAMDATA% è la variabile di ambiente che definisce la directory di lavoro del sistema. La directory predefinita dipende dal sistema operativo.
Se i problemi persistono, svuotare wsplugin6.conf, riavviare il nodo di integrazione e ridistribuire i flussi di messaggi.

Quando si utilizzano le connessioni sicure HTTP, si modifica la destinazione di un host DNS ma il nodo di integrazione utilizza una definizione di host DNS memorizzata nella cache

Procedura

Scenario: si sta utilizzando un nodo di integrazione con connessioni sicure HTTP che utilizzano la macchina virtuale Java™ ( JVM ). È stata modificata una destinazione DNS, ma il nodo di integrazione utilizza una definizione host DNS memorizzata nella cache, pertanto è necessario riavviare il nodo di integrazione per utilizzare la nuova definizione.
Spiegazione: per impostazione predefinita, Java memorizza nella cache la ricerca host da DNS, il che non è appropriato se si desidera ricercare il nome host ogni volta o se si desidera memorizzarlo nella cache per un periodo di tempo limitato. Questa situazione si verifica solo se si utilizzano connessioni SSL. (Quando si utilizza una connessione sicura HTTPS, il nodo HTTPRequest impiega il protocollo SSL, che effettua chiamate Java, mentre un protocollo non SSL utilizza chiamate native.)
Per evitare questa situazione, è possibile svuotare la cache su JVM impostando la proprietà networkaddress.cache.ttl su zero. Questa proprietà è responsabile della politica di memorizzazione nella cache per ricerche di nome con esito positivo per il servizio nomi. Il valore viene specificato in forma di numero intero a indicare per quanti secondi memorizzare nella cache la ricerca con esito positivo. Il valore predefinito di questa proprietà è -1, che indica che il valore della ricerca di DNS con esito positivo viene memorizzato nella cache per un tempo indefinito in JVM. Se si imposta la proprietà su 0 (zero), la ricerca DNS con esito positivo non viene memorizzata nella cache.
Soluzione: per applicare le modifiche alle voci DNS senza dover arrestare e riavviare il nodo di integrazione e JVM, disattivare la cache DNS.
Modificare il file $JAVA_HOME/jre/lib/security/java.security, e impostare il valore della proprietà networkaddress.cache.ttl su 0 (zero).
Quindi, esegui il seguente comando:
```
mqsichangeproperties <INodeName> -e <IntegrationServer> -o ComIbmJVMManager -n jvmSystemProperty -v "-Dsun.net.inetaddr.ttl=0"
```

Il nodo TimeoutControl emette il messaggio di errore BIP4606 o BIP4607 quando l'ora di inizio della richiesta di timeout che riceve è nel passato

Procedura

Scenario: quando un nodo TimeoutControl riceve un messaggio di richiesta di timeout che contiene un'ora di avvio nel passato, emette il messaggio di errore BIP4606 o BIP4607:The Timeout Control Node '&2' received a timeout request that did not contain a valid timeout start date/time value.
Spiegazione: l'ora di avvio nel messaggio può essere calcolata aggiungendo un intervallo all'ora corrente. Se si verifica un ritardo tra il nodo che calcola l'ora di inizio e il nodo TimeoutControl , l'ora di inizio nel messaggio sarà passata dal momento in cui raggiunge il nodo TimeoutControl . Se l'ora di inizio è superiore a circa cinque minuti nel passato, viene emessa un'avvertenza e il nodo TimeoutControl rifiuta la richiesta di timeout. Se l'ora di inizio è menodi cinque minuti nel passato, la richiesta viene elaborata dal nodo come se fosse immediata.
Soluzione: verificare che l'ora di inizio nel messaggio di richiesta di timeout sia un'ora futura.

Si sta utilizzando un nodo TimeoutControl con un nodo TimeoutNotification , con più client in esecuzione contemporaneamente e i messaggi sembrano essere stati eliminati

Procedura

Scenario Si sta utilizzando un nodo TimeoutControl con un nodo TimeoutNotification , con più client in esecuzione contemporaneamente e i messaggi sembrano essere eliminati. Nel messaggio di richiesta timeout, l'opzione allowOverwrite si utilizza per TRUE.
Spiegazione: se più client sono in esecuzione contemporaneamente e allowOverwrite è impostata su TRUE nel messaggio di richiesta di timeout, i messaggi possono sovrascriversi reciprocamente.
Soluzione: assicurarsi che i diversi nodi TimeoutNotification distribuiti sullo stesso nodo di integrazione non condividano lo stesso identificativo univoco.

Il messaggio di errore BIP5347 viene emesso su AIX quando si esegue un flusso di messaggi che utilizza una serie di messaggi

Informazioni su questa attività

Procedura

Scenario: messaggio di errore BIP5347 (MtilmbParser2: RM has thrown an unknown exception) viene emesso su AIX® in una delle seguenti circostanze:
- Quando si distribuisce una serie di messaggi
- Quando si esegue un flusso di messaggi che utilizza una serie di messaggi
Spiegazione: BIP5347 in genere è causato da un'eccezione di database e viene emesso quando un server di integrazione tenta di caricare un dizionario MRM per l'utilizzo da parte di un flusso di messaggi. Questo processo è composto da due fasi:
1. Il server di integrazione richiama i descrittori del dizionario e wire format dall'archivio dati del nodo di integrazione.
2. Il server di integrazione memorizza il dizionario nella memoria che un flusso di messaggi utilizzerebbe per elaborare un messaggio MRM.
Generalmente BIP5347 viene emesso durante il passo 1. Questo problema può sembrare intermittente; se si riavvia il server di integrazione, a volte il messaggio viene elaborato correttamente.

BIP5347 può essere causato anche dalla presenza di un vincolo del valore data/ora nella serie di messaggi, che genera l'errore ad ogni distribuzione della serie di messaggi.
Soluzione: per identificare la causa dell'errore, acquisire una traccia di debug del livello del servizio per confermare che si sta verificando l'eccezione del database.
- Se l'errore è causato dalla presenza di un vincolo del valore data/ora, viene visualizzato un messaggio simile al seguente nella traccia di debug del livello di servizio (il messaggio esatto dipende dal vincolo data/ora nella serie di messaggi):
```
Unable to parse datetime internally, 9, 2001-12-17T09:30:47.0Z, 
yyyy-MM-dd'T'HH:mm:ss.SZZZ  
```
  Questo errore si verifica poiché l'elemento MRM in questione ha un valore data/ora non compatibile con la stringa in formato data/ora, quindi il dizionario viene respinto. Per risolvere tale problema, verificare che il valore data/ora sia compatibile con la stringa in formato data/ora.

Emissione del messaggio di errore BIP2130 con valore di codepage -1 o -2

Procedura

Scenario: viene emesso il seguente messaggio di errore:
```
BIP2130: errore di conversione di una stringa di caratteri in o da una
codepage [valore codepage]
```
Dove[code page value]è uno dei due -1 O -2. Non è stata, tuttavia, specificata una codepage -1 o -2 nella struttura ad albero dei messaggi. Hai tuttavia utilizzato una delle costanti IBM MQ, ovvero MQCCSI_EMBEDDED o MQCCSI_INHERIT.
Spiegazione: Le costanti MQCCSI_EMBEDDED e MQCCSI_INHERIT dell' IBM MQ e vengono risolte quando l'intero albero dei messaggi viene serializzato per generare il flusso di bit dell' IBM MQ. Ciò accade quando il messaggio viene inserito nel trasporto IBM MQ. Fino a quel momento, tali valori esistono nella struttura ad albero dei messaggi come -1 (per MQCCSI_EMBEDDED) o -2 (per MQCCSI_INHERIT). Se una o più parti dell'albero dei messaggi vengono serializzate in modo indipendente, ad esempio tramite un nodo " ResetContentDescriptor " o una funzione ESQL ASBITSTREAM, si verifica questo errore.
Soluzione: Non è necessario impostare MQCCSI_EMBEDDED o MQCCSI_INHERIT nella struttura dei messaggi CodedCharSetId campo. È possibile ottenere lo stesso risultato impostando esplicitamente il CodedCharSetId richiesto sul valore CodedCharSetId dell'intestazione precedente. Ad esempio, è necessario sostituire:
```
SET OutputRoot.MQRFH2.(MQRFH2.Field)CodedCharSetId = MQCCSI_INHERIT;
```
con
```
SET OutputRoot.MQRFH2.(MQRFH2.Field)CodedCharSetId = InputRoot.MQMD.CodedCharSetId;
```
dove la cartella MQMD è l'intestazione che precede l'intestazione MQRFH2.

Il server di integrazione viene riavviato prima che un nodo MQGet abbia richiamato tutti i messaggi

Procedura

Scenario: è stato creato un flusso di messaggi che contiene un nodo MQGet . Non tutti i messaggi vengono richiamati dalla coda perché il server di integrazione si riavvia prima che il nodo abbia richiamato tutti i messaggi. Non viene generato alcun file abend.
Spiegazione: In IBM App Connect Enterprise, le operazioni che comportano elaborazioni annidate o ricorsive possono causare un uso intensivo dello stack. L'elaborazione del flusso di messaggi si verifica in un loop finché il nodo MQGet non ha richiamato tutti i messaggi dalla coda. Ogni volta che l'elaborazione ritorna al nodo MQGet , la dimensione dello stack aumenta.
Soluzione: utilizzare un'istruzione PROPAGATE. L'istruzione propaga ogni messaggio in un loop attraverso il flusso di messaggi, ma ogni volta che l'elaborazione ritorna all'istruzione PROPAGATE, la stack viene eliminata.
Utilizzare una variabile ESQL (ad esempio, impostare Environment.Complete su true) nella struttura ad albero dell'ambiente per terminare il loop ESQL, arrestare le propagazioni e attendere il successivo messaggio di trigger. Se è necessario memorizzare il contenuto proveniente dai messaggi, memorizzarlo nella struttura ad albero dell'ambiente perché le altre strutture ad albero vengono cancellate quando l'elaborazione del flusso di messaggi torna all'istruzione PROPAGATE. Per ulteriori informazioni su come utilizzare questa istruzione, consultare Istruzione PROPAGATE.