Uso del routing dei messaggi non riuscito

La funzionalità di gestione degli errori consente alla finestra di progettazione di designare la gestione automatica degli errori di messaggistica come alternativa al comportamento tradizionale (ora predefinito) dell'inserimento di messaggi non riusciti nella coda Sospesa. Questa gestione automatizzata indirizza un messaggio di errore a qualsiasi destinazione di routing abbonata, ad esempio una porta di invio o un'orchestrazione. Il messaggio di errore è un clone del messaggio originale con tutte le proprietà precedentemente promosse ora retrocesse e con le proprietà selezionate relative all'errore di messaggistica specifico promosse al contesto del messaggio.

Avvertimento

I messaggi non riusciti contengono una copia del messaggio originale. Se il messaggio originale contiene informazioni riservate, progettare i processi di messaggi manuali e automatici non riusciti in modo da evitare la divulgazione accidentale.

In cosa consiste il routing dei messaggi non riusciti?

Quando il routing dei messaggi non è riuscito è abilitato, BizTalk Server non sospende il messaggio, ma instrada il messaggio. Il routing dei messaggi non riuscito può essere abilitato su entrambe le porte di ricezione e invio, con i risultati seguenti:

• Se il routing dei messaggi non riuscito è abilitato su una porta di ricezione e un messaggio non riesce nella pipeline di ricezione o nel routing, viene generato un messaggio non riuscito. Nel caso in cui si verifichi un errore in o prima della fase disassembly, il messaggio di errore è un clone dell'interscambio originale.

• Se il routing dei messaggi non riuscito è abilitato su una porta di trasmissione e il messaggio non riesce nella pipeline di trasmissione, viene generato un messaggio non riuscito.

  Quando viene generato un messaggio non riuscito, BizTalk Server promuove le proprietà del contesto del messaggio correlate al report degli errori e abbassa di livello le normali proprietà del contesto del messaggio prima di pubblicare il messaggio non riuscito. Confrontare questo comportamento con il comportamento predefinito quando il routing dei messaggi non riuscito non è abilitato: i messaggi che hanno esito negativo vengono sospesi.

Quali tipi di errori di messaggistica attivano un messaggio di errore?

Qualsiasi errore che si verifica durante l'elaborazione dell'adapter, l'elaborazione della pipeline, il mapping o il routing dei messaggi genera un messaggio di errore se il routing per i messaggi non riusciti è abilitato. Quando si verifica un errore di messaggistica durante la ricezione di un'orchestrazione da una porta di ricezione o l'invio a una porta di trasmissione, il messaggio di errore risultante è associato alle porte di messaggistica a cui è associata l'orchestrazione.

Sottoscrizione di un messaggio di errore

I messaggi di errore vengono recapitati alle orchestrazioni o alle porte di trasmissione sottoscritte per riceverle. Una sottoscrizione seleziona in genere un messaggio di errore in base al nome della porta in cui si è verificato l'errore di messaggistica (una porta di trasmissione o di ricezione). Una sottoscrizione potrebbe anche filtrare in base ad altre proprietà promosse al contesto del messaggio dell'errore, ad esempio InboundTransportLocation o FailureCode.

Specifica del messaggio di errore

Un messaggio di errore è una copia del messaggio originale non riuscito, con tutte le proprietà promosse in precedenza retrocesse e con un set di proprietà specifiche di errore promosse al contesto del messaggio. Le proprietà in precedenza promosse vengono retrocesse per evitare la consegna non intenzionale agli iscritti non designati per 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à che sono promosse al contesto di un messaggio di errore rientrano tutte nello spazio dei nomi ErrorReport in BizTalk Server. Sono i seguenti:

Nome della proprietà	Tipo di dati	Promosso	Descrizione
Codice di errore	xs:string	Sì	Codice di errore. Valore esadecimale segnalato nella console di amministrazione di BizTalk Server.
Categoria di guasto	xs:int	Sì	Questa proprietà non viene utilizzata. Il valore non è definito.
Descrizione	xs:string	NO	Descrizione dell'errore. Lo stesso testo di diagnostica scritto nel registro eventi dell'applicazione relativo a questo errore di messaggistica.
TipoDiMessaggio	xs:string	Sì	Tipo di messaggio non riuscito o vuoto se il tipo di messaggio è indeterminato. BizTalk Server usa il tipo di messaggio per associare i messaggi ai relativi XML Schema. Il tipo di messaggio viene 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 hanno questa proprietà impostata.
ReceivePortName	xs:string	Alzata di livello se l'errore si è verificato durante l'elaborazione in ingresso (in una porta di ricezione) Non alzato di livello se l'errore si è verificato in una porta di trasmissione.	Nome della porta di ricezione in cui si è verificato l'errore.
InboundTransportLocation	xs:string	Alzata di livello se l'errore si è verificato durante l'elaborazione in ingresso (in una porta di ricezione) Non alzato di livello se l'errore si è verificato in una porta di trasmissione.	URI della posizione di ricezione in cui si è verificato l'errore.
SendPortName	xs:string	Alzata di livello se l'errore si è verificato durante l'elaborazione in uscita (in una porta di trasmissione) Non alzato di livello se l'errore si è verificato in una porta di ricezione.	Nome della porta di trasmissione in cui si è verificato l'errore.
OutboundTransportLocation	xs:string	Alzata di livello se l'errore si è verificato durante l'elaborazione in uscita (in una porta di trasmissione) Non alzato di livello se l'errore si è verificato in una porta di ricezione.	URI del percorso di invio in cui si è verificato l'errore.
Tipo di Errore	xs:string	Sì	Indica il tipo di messaggio che contiene l'errore. Questa proprietà contiene sempre il valore FailedMessage, vale a dire che l'errore contiene il messaggio originale non riuscito.
IDRapportoDiErroreDiInstradamento	xs:string	Sì	Questa proprietà fornisce l'ID del report degli errori di routing generato da BizTalk Server quando si verifica un errore di routing. Un report sugli errori di routing è un messaggio speciale che bizTalk Server genera e sospende. Questo messaggio non ha un corpo, ma ha il contesto del messaggio non riuscito. Usando questo ID, un'orchestrazione di gestione degli errori o una porta di trasmissione può eseguire una query sul database MessageBox ed elaborare il report degli errori di routing. Ad esempio, un'orchestrazione potrebbe voler terminare il report degli errori di routing dopo aver ricevuto il messaggio non riuscito.
FailureTime	xs:dateTime		Data dell'occorrenza dell'errore
IDMessaggioErrore	xs:string
FailureInstanceID	xs:string
FailureAdapter	xs:string

Gestione dei messaggi di errore

La gestione degli errori viene specificata da una sottoscrizione di orchestrazione o di porta di invio, il cui filtro corrisponde alle proprietà promosse al contesto del messaggio di errore.

Implicazioni per la sicurezza

L'identità associata al messaggio originale, ovvero l'identità iniziale o l'identità finale determinata dalla fase Resolve Party della pipeline di ricezione, viene assegnata al messaggio di errore.

I meccanismi di sicurezza che limitano il recapito dei messaggi alle porte e alle orchestrazioni di sottoscrizione autorizzate si applicano anche ai messaggi di errore.

Una porta di trasmissione che sottoscrive un messaggio di errore, ma non è configurata con un certificato di decrittografia appropriato, non riceve messaggi di errore che derivano da errori di messaggistica in o prima della fase di decrittografia della pipeline di ricezione tramite cui il messaggio originale ha immesso BizTalk Server. I messaggi non riusciti vengono invece inseriti nella coda Sospesa.

Errore di messaggistica dell'adapter

Se un adattatore sospende un messaggio, viene pubblicato un messaggio di errore. Se il messaggio non è sospeso, non viene generato alcun messaggio di errore.

Pipeline di ricezione transazionali

Se una pipeline di ricezione transazionale genera un'eccezione (specifica che la transazione deve essere interrotta), la transazione viene interrotta e viene pubblicato un messaggio di errore.

Se una pipeline di ricezione transazionale sospende esplicitamente un messaggio (specificando che MessageDestination = SuspendQueue), la transazione corrente è autorizzata a procedere (e può essere confermata a meno che le fasi successive non decidano di abortirla) e il messaggio di errore risultante viene pubblicato.

Solicit-Response Porte di invio

Quando un messaggio di richiesta viene inviato da un'orchestrazione e la trasmissione non riesce o la risposta non riesce nell'elaborazione in ingresso, l'orchestrazione ottiene un'eccezione, indipendentemente dal fatto che il messaggio non riuscito sia stato indirizzato.

Nel caso in cui una porta di trasmissione solicit-response sia connessa a una porta di ricezione request-response, la porta di ricezione ottiene un messaggio di risposta (se la trasmissione riesce) o un NACK (se la trasmissione ha esito negativo), indipendentemente dal fatto che il messaggio non riuscito sia stato instradato.

One-Way Porte di Invio

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 indipendentemente dal fatto che il messaggio di errore sia stato indirizzato. In altre parole, la porta di trasmissione genera una notifica di consegna per l'orchestrazione anche se la porta incontra un errore di messaggistica durante l'elaborazione. La notifica conferma il recapito al porto, ma non affronta l'elaborazione corretta tramite il porto.

Ripresa dei messaggi sospesi

La maggior parte dei messaggi che non superano l'elaborazione in ingresso, ovvero l'elaborazione dall'adattatore di ricezione fino alla pubblicazione nella casella dei messaggi, e i cui errori non sono gestiti, vengono sospesi come ripristinabili. L'eccezione è che i messaggi di richiesta da porte di ricezione bidirezionali vengono sospesi come non ripristinabili.

I messaggi vengono in genere sospesi nel formato originale (come prima dell'elaborazione della pipeline), con due eccezioni:

• Messaggi sospesi dai componenti della pipeline. BizTalk Server sospende questo tipo di messaggio nello stesso formato in cui è stato fornito al componente della pipeline che fallisce. Quando il messaggio viene ripreso, viene sottoposto all'elaborazione della pipeline dall'inizio di essa. Ciò implica che un componente della pipeline in una fase della pipeline che precede la fase in cui si è verificato l'errore originale deve essere preparato per gestire il messaggio "stesso" in un formato diverso dal formato originale in cui ha elaborato il messaggio.

• Messaggi provenienti dal disassemblaggio di un interscambio recuperabile che successivamente non viene instradato. BizTalk Server sospende questo tipo di messaggio nello stesso formato in cui è stato pubblicato. Questo è il formato che il messaggio aveva dopo l'esecuzione della pipeline. Quando il messaggio viene ripreso, ignora l'elaborazione della pipeline e viene pubblicata direttamente nel database MessageBox.

Scenari che portano a messaggi sospesi (non ripristinabili)

Sebbene sia più comune sospendere i messaggi come ripristinabili, esistono alcuni scenari che portano a messaggi non ripristinabili:

• In una porta di trasmissione recapito ordinato con continuazione in caso di errore abilitato, in caso di errore nella pipeline, nel mapping o nella trasmissione.

• In una porta di ricezione per Recapito ordinato, se l'adapter è configurato per sospendere i messaggi in caso di guasto non ripristinabile. Ad esempio, se l'impostazione dell'adattatore MSMQ "In caso di errore" è impostata su "Suspend (non ripristinabile)" o l'adattatore MQSeries ha abilitato "Suspend as Non Resumable", i messaggi non riusciti verranno sospesi come non ripristinabili.

• In una porta di ricezione bidirezionale, se il messaggio di risposta fallisce nel passaggio della pipeline, nel processo di mapping o nella trasmissione.

• In una porta di ricezione bidirezionale, se il messaggio di ricezione non riesce nella pipeline, nella mappatura o nella trasmissione. Il comportamento di un singolo adattatore può essere diverso. Ad esempio, l'adapter HTTP non sospende i messaggi per impostazione predefinita, ma può essere configurato per farlo.

Vedere anche

gestione degli errori
Uso dei riconoscimenti
Recapito ordinato dei messaggi