Utilizzo del routing dei messaggi non riusciti
La nuova funzionalità di gestione degli errori consente di impostare la gestione automatica degli errori di messaggistica come alternativa al comportamento tradizionale (oggi predefinito), che consiste nell'inserire i messaggi non riusciti nella coda degli elementi sospesi. Con la gestione automatica i messaggi di errore vengono instradati a una destinazione di routing di sottoscrizione, quale una porta di trasmissione o un'orchestrazione. Il messaggio di errore è un clone del messaggio originale con tutte le proprietà precedentemente alzate di livello ora abbassate di livello e le proprietà selezionate correlate all'errore specifico di messaggistica alzate di livello al contesto del messaggio.
Avviso
I messaggi non riusciti contengono una copia del messaggio originale. Se il messaggio originale contiene informazioni riservate, progettare i processi manuali e automatici dei messaggi non riusciti in modo da evitare la divulgazione accidentale.
Natura del routing dei messaggi non riusciti
Quando è attivato il routing dei messaggi non riusciti, il messaggio non viene sospeso ma instradato. È possibile attivare il routing dei messaggi non riusciti sia sulle porte di ricezione sia sulle porte di trasmissione, con i seguenti risultati:
Se su una porta di ricezione è attivato il routing dei messaggi non riusciti e per un messaggio si verifica un errore nella pipeline di ricezione o nel routing, viene generato un messaggio di errore. Nel caso in cui l'errore si verifichi prima o durante la fase di disassemblaggio, il messaggio di errore sarà un clone dell'interscambio originale.
Se su una porta di trasmissione è attivato il routing dei messaggi non riusciti e per un messaggio si verifica un errore nella pipeline di trasmissione, viene generato un messaggio di errore.
Quando viene generato un messaggio di errore, le proprietà del contesto del messaggio correlate alla segnalazione errori vengono alzate di livello, mentre le proprietà del contesto del messaggio normale vengono abbassate di livello prima di pubblicare il messaggio di errore. Confrontando questo funzionamento con il comportamento predefinito quando non è attivato il routing dei messaggi non riusciti si osserva che i messaggi con errori vengono sospesi.
Tipi di errori di messaggistica che danno luogo alla generazione di un messaggio di errore
Tutti gli errori che si verificano nell'elaborazione dell'adapter o della pipeline, nel mapping o nel routing di messaggi causano la generazione di un messaggio di errore se è attivato il routing per i messaggi non riusciti. Quando si verifica un errore di messaggistica mentre un'orchestrazione sta ricevendo da una porta di ricezione o inviando a una porta di trasmissione, il messaggio di errore che viene generato è associato alle porte di messaggistica alle quali è associata l'orchestrazione.
Sottoscrizione di un messaggio di errore
I messaggi di errore vengono recapitati alle orchestrazioni o alle porte di trasmissione che hanno eseguito la sottoscrizione per riceverli. Di solito una sottoscrizione seleziona i messaggi di errore in base al nome della porta sulla quale si è verificato l'errore, ossia una porta di trasmissione o ricezione. Nell'ambito della sottoscrizione è inoltre possibile aggiungere un filtro ad altre proprietà alzate di livello al contesto del messaggio di errore, InboundTransportLocation o FailureCode, ad esempio.
Specifica del messaggio di errore
Un messaggio di errore è un clone del messaggio originale non riuscito, con tutte le proprietà precedentemente alzate di livello ora abbassate di livello e con un set di proprietà specifiche per l'errore alzato di livello al contesto del messaggio. Le proprietà in precedenza alzate di livello vengono ora abbassate di livello per evitare il recapito non intenzionale a sottoscrittori che non devono ricevere il messaggio di errore. Il messaggio di errore viene pubblicato per la distribuzione ai sottoscrittori (orchestrazioni, porte di trasmissione e gruppi di porte di trasmissione).
Le proprietà promosse al contesto di un messaggio di errore rientrano nello spazio dei nomi ErrorReport in BizTalk Server. Ecco quali sono:
| Nome proprietà | Tipo di dati | Innalzata | Descrizione |
|---|---|---|---|
| FailureCode | xs:string | Sì | Codice di errore. Valore esadecimale segnalato nella console di amministrazione di BizTalk Server. |
| FailureCategory | xs:int | Sì | Questa proprietà non viene utilizzata. Il relativo valore non è definito. |
| Descrizione | xs:string | No | Descrizione errore. Stesso testo di diagnostica riportato nel registro eventi delle applicazioni per questo errore di messaggistica. |
| MessageType | xs:string | Sì | Tipo dei messaggi non riusciti o vuoto se il tipo di messaggio è indeterminato. In BizTalk Server il tipo di messaggio viene utilizzato per associare i messaggi agli schemi XML. Il tipo di messaggio è formato concatenando lo spazio dei nomi dello schema con il nodo radice dello schema: http://mynamespace#rootnode. Nota: I messaggi che hanno esito negativo prima che il tipo di messaggio venga determinato non disponga di questa proprietà impostata. |
| ReceivePortName | xs:string | Alzata di livello se l'errore si è verificato durante l'elaborazione in ingresso su una porta di ricezione. Non alzata di livello se l'errore si è verificato su una porta di trasmissione. |
Nome della porta di ricezione sulla quale si è verificato l'errore. |
| InboundTransportLocation | xs:string | Alzata di livello se l'errore si è verificato durante l'elaborazione in ingresso su una porta di ricezione. Non alzata di livello se l'errore si è verificato su una porta di trasmissione. |
URI dell'indirizzo di ricezione nel quale si è verificato l'errore. |
| SendPortName | xs:string | Alzata di livello se l'errore si è verificato durante l'elaborazione in uscita su una porta di trasmissione. Non alzata di livello se l'errore si è verificato su una porta di ricezione. |
Nome della porta di trasmissione sulla quale si è verificato l'errore. |
| OutboundTransportLocation | xs:string | Alzata di livello se l'errore si è verificato durante l'elaborazione in uscita su una porta di trasmissione. Non alzata di livello se l'errore si è verificato su una porta di ricezione. |
URI dell'indirizzo di trasmissione nel quale si è verificato l'errore. |
| ErrorType | xs:string | Sì | Indica il tipo di messaggio contenuto nell'errore. Questa proprietà contiene sempre il valore FailedMessage, ad indicare che l'errore contiene il messaggio originale non riuscito. |
| RoutingFailureReportID | xs:string | Sì | Questa proprietà fornisce l'ID del rapporto errore di routing generato in BizTalk Server quando si verifica un errore di routing. Il rapporto errore di routing è un messaggio speciale che viene generato e sospeso in BizTalk Server. Questo messaggio non ha corpo ma contiene il contesto del messaggio non riuscito. Utilizzando questo ID, un'orchestrazione di gestione errori o una porta di trasmissione può inviare una query al database MessageBox ed elaborare il rapporto errore di routing. È ad esempio è possibile per un'orchestrazione terminare il rapporto errore di routing dopo avere ricevuto il messaggio non riuscito. |
| FailureTime | xs:dateTime | Data dell'occorrenza dell'errore | |
| FailureMessageID | xs:string | ||
| FailureInstanceID | xs:string | ||
| FailureAdapter | xs:string |
Gestione dei messaggi di errore
La gestione errori è specificata da una sottoscrizione di un'orchestrazione o di una porta di trasmissione il cui filtro corrisponde alle proprietà che sono state alzate di livello al contesto del messaggio di errore.
Implicazioni della sicurezza
Al messaggio di errore viene assegnata l'identità associata al messaggio originale, ovvero l'identità iniziale o finale del messaggio, in base a quanto determinato dalla fase di risoluzione entità della pipeline di ricezione.
I meccanismi di sicurezza che limitano il recapito di messaggi alle porte e alle orchestrazioni di sottoscrizione autorizzate si applicano anche ai messaggi di errore.
Una porta di trasmissione che esegue la sottoscrizione di un messaggio di errore senza essere configurata con il corretto certificato di decrittazione non riceverà i messaggi di errore derivanti da errori di messaggistica generati prima o durante la fase di decrittazione della pipeline di ricezione tramite la quale il messaggio originale è stato immesso in BizTalk Server. I messaggi non riusciti verranno invece inseriti nella coda degli elementi sospesi.
Errore di messaggistica dell'adapter
Se un adapter sospende un messaggio, viene pubblicato un messaggio di errore. Non viene generato alcun messaggio di errore se il messaggio non viene sospeso.
Pipeline di ricezione transazionali
Se una pipeline di ricezione transazionale genera un'eccezione (viene specificato che la transazione deve essere interrotta), la transazione verrà interrotta e verrà pubblicato un messaggio di errore.
Se una pipeline di ricezione transazionale sospende esplicitamente un messaggio (viene specificato MessageDestination = SuspendQueue), la transazione corrente verrà autorizzata a procedere, per essa potrà essere eseguito il commit, a meno che non venga specificato di interromperla in fasi seguenti, e il messaggio di errore che ne risulta verrà pubblicato.
Porte di trasmissione sollecitazione-risposta
Quando un messaggio di richiesta viene inviato da un'orchestrazione e la trasmissione non riesce o la relativa risposta non riesce in fase di elaborazione di ingresso, l'orchestrazione riceve un'eccezione a prescindere dal fatto che il messaggio non riuscito sia o non sia stato instradato.
Nel caso in cui una porta di trasmissione sollecitazione-risposta sia collegata a una porta di ricezione richiesta-risposta, la porta di ricezione riceve un messaggio di risposta (se la trasmissione ha esito positivo) o un NACK (se la trasmissione ha esisto negativo) a prescindere dal fatto che il messaggio non riuscito sia o non sia stato instradato.
Porte di trasmissione unidirezionali
Quando un messaggio viene inviato da un'orchestrazione tramite una porta di trasmissione configurata per la notifica di recapito, l'orchestrazione riceve una notifica di recapito a prescindere dal fatto che il messaggio di errore sia stato o non sia instradato. Vale a dire che la porta di trasmissione genera una notifica di recapito per l'orchestrazione anche se durante l'elaborazione viene riscontrato un errore di messaggistica. La notifica conferma l'avvenuto recapito alla porta ma non risolve i problemi di elaborazione presso la porta.
Ripristino dei messaggi sospesi
La maggior parte dei messaggi che non superano l'elaborazione di ingresso (ossia l'elaborazione a partire dall'adapter di ricezione incluso, fino alla pubblicazione alla finestra di messaggio non inclusa) e i cui errori non sono gestiti, vengono sospesi come ripristinabili. L'eccezione consiste nella sospensione come non ripristinabili dei messaggi di richiesta dalle porte di ricezione bidirezionali.
Di norma i messaggi vengono sospesi nel formato originale, ossia come si presentavano prima di essere elaborati nella pipeline, con due eccezioni:
Messaggi sospesi da componenti della pipeline. I messaggi di questo tipo vengono sospesi nello stesso formato in cui sono stati forniti al componente della pipeline nel quale si è verificato l'errore. Quando il messaggio viene ripristinato, viene sottoposto a elaborazione nella pipeline dall'inizio della pipeline stessa. Ciò implica la necessità da parte di un componente della pipeline che si trova in una fase precedente la fase in cui si è verificato l'errore originale, di essere preparato a gestire lo "stesso" messaggio in un formato diverso dal formato originale in cui il messaggio era stato elaborato.
Messaggi dal disassemblaggio dell'interscambio reversibile per i quali il routing successivamente non riesce. I messaggi di questo tipo vengono sospesi nello stesso formato in cui sono stati pubblicati. Si tratta del formato del messaggio dopo l'esecuzione nella pipeline. Quando il messaggio viene ripristinato, l'elaborazione nella pipeline viene ignorata e il messaggio viene pubblicato direttamente nel database MessageBox.
Scenari che determinano la sospensione dei messaggi (non ripristinabili)
Nonostante sia più frequente il caso dei messaggi che vengono sospesi ma che possono essere ripristinati, sono anche possibili gli scenari in cui i messaggi sospesi non sono ripristinabili:
In una porta di trasmissione del recapito ordinato in cui è attivata la continuazione in caso di errore, se si verifica un errore nella pipeline, nel mapping o nella trasmissione.
In una porta di ricezione del recapito ordinato, se l'adapter è configurato per sospendere i messaggi come non ripristinabili in caso di errore. Se, ad esempio, l'opzione "In caso di esito negativo" dell'adapter MSMQ è impostata su "Sospendi (non può essere ripristinato)" o se per l'adapter MQSeries è attivata l'opzione "Sospendi come non ripristinabile", i messaggi non riusciti verranno sospesi e non potranno essere ripristinati.
In una porta di ricezione bidirezionale, se il messaggio di risposta non riesce nella pipeline, nel mapping o nella trasmissione.
In una porta di ricezione bidirezionale, se il messaggio di ricezione non riesce nella pipeline, nel mapping o nella trasmissione. È possibile che il funzionamento di ogni specifico adapter sia diverso. L'adapter http, ad esempio, non sospende i messaggi per impostazione predefinita ma può essere configurato in tal senso.
Vedere anche
Gestione degli errori
Utilizzo dei riconoscimenti
Recapito ordinato dei messaggi