Esporta (0) Stampa
Espandi tutto

Azioni di routing e di inoltro: Bridging della mancata corrispondenza dei protocolli

Aggiornamento: ottobre 2014

La mancata corrispondenza del protocollo si verifica quando il mittente e il ricevitore del messaggio usano protocolli di messaggio diversi. In uno scenario tipico di Servizi BizTalk in cui sono presenti bridge, un mittente invia un messaggio al bridge. Il bridge elabora il messaggio e lo invia al ricevitore di messaggi. Questo significa che deve essere eseguito il bridging della mancata corrispondenza del protocollo nei due casi seguenti:

  • Il primo, quando il messaggio viene inviato al ricevitore di messaggi. Questo vale sia per il Bridge XML unidirezionale che per il Bridge XML di richiesta/risposta perché in entrambi i casi il messaggio deve essere inviato al ricevitore di messaggi. Questa operazione è denominata Azione route.

  • Il secondo, quando il messaggio di risposta ricevuto dal ricevitore di messaggi viene inviato al mittente del messaggio. Questo si applica solo al Bridge XML di richiesta/risposta, perché solo per questo bridge deve essere inviata una risposta al mittente del messaggio. Questa operazione è denominata Azione di risposta.

Entrambe le azioni route e di inoltro operano sulle proprietà definite nella fase Enrich.

Verrà usato uno scenario per comprendere come è possibile usare l'azione route per la mancata corrispondenza dei protocolli. In base allo scenario, deve essere inviato un messaggio POX (Plain Old XML)/REST al servizio WCF (che prevede un messaggio SOAP) tramite un Bridge XML unidirezionale. Il messaggio inviato al bridge è un semplice payload XML senza intestazioni. Per il messaggio in uscita al servizio WCF è invece necessario definire alcune intestazioni SOAP. Per eseguire il bridging di questa mancata corrispondenza del protocollo, il soggetto che configura il bridge usa l'azione route per assegnare alcune intestazioni del messaggio SOAP pertinenti, ad esempio Action, MessageID e così via, al messaggio in uscita. Dopo aver configurato e distribuito il bridge nel Service Bus, il messaggio POX viene inviato al bridge. Dopo avere elaborato il messaggio ma prima del routing del messaggio al servizio WCF, le intestazioni specificate nell'azione route del bridge vengono applicate al messaggio e quindi inviate al servizio WCF, eseguendo così il bridging della mancata corrispondenza del protocollo. Per configurare un'azione route, vedere The Routing Action.

Nella tabella seguente viene descritto come è possibile trasferire i valori delle proprietà tra fasi intermedie (o la destinazione) di un Progetto del servizio BizTalk usando le azioni route:

 

Da/A Ad altri bridge A code e argomenti A endpoint servizio esterni o di inoltro

Dai bridge

Non è possibile trasferire le proprietà così come sono (coppie chiave-valore), ma possono essere passate assegnandole come valori di intestazioni dei messaggi in uscita (HTTP o SOAP).

È possibile trasferire le proprietà così come sono (coppie chiave-valore) e possono anche essere passate come valori di intestazioni dei messaggi in uscita.

Non è possibile trasferire le proprietà così come sono (coppie chiave-valore), ma possono essere passate assegnandole come valori di intestazioni dei messaggi in uscita (HTTP o SOAP). Tuttavia, è prerogativa del progettista del bridge assicurarsi che le intestazioni pertinenti, che possono essere usate dall'inoltro o dal servizio esterno, vengano passate.

L'azione di risposta è simile all'azione route. La differenza sta nel fatto che mentre l'azione route si applica quando il messaggio viene inviato al ricevitore del messaggio indicato (nel Bridge XML unidirezionale o nel Bridge XML di richiesta/risposta), l'azione di risposta si applica quando il messaggio di risposta da un ricevitore di messaggi deve essere di nuovo instradato al mittente del messaggio (solo nel caso del Bridge XML di richiesta/risposta).

Per comprendere meglio questo concetto, è sufficiente invertire lo scenario usato per l'azione route. Si supponga che il mittente del messaggio debba inviare un messaggio SOAP al servizio REST che prevede un messaggio POX/REST tramite un Bridge XML di richiesta/risposta. Il messaggio inviato al bridge è un messaggio SOAP con tutte le intestazioni pertinenti. Il bridge, prima di instradare il messaggio al servizio REST, rimuove in modo implicito le intestazioni dei messaggi e invia solo il payload XML al servizio REST. Anche la risposta dal servizio REST è un messaggio POX. Prima che il messaggio di risposta POX venga di nuovo inviato al mittente del messaggio, l'azione di risposta applica le intestazioni del messaggio nel messaggio POX e quindi invia un messaggio SOAP protetto digitalmente al mittente del messaggio. Per configurare un'azione di risposta, vedere XML Request-Reply Bridge : Configuring the Reply Action Before Routing the Response Message.

Nella tabella seguente viene illustrato come è possibile ritrasferire i valori delle proprietà da un bridge al client che ha inviato il messaggio usando le azioni di risposta:

 

Da/A Ad altri bridge A endpoint servizio esterni o di inoltro

Dai bridge

Non è possibile trasferire le proprietà così come sono (coppie chiave-valore), ma possono essere passate assegnandole come valori di intestazioni dei messaggi in uscita (HTTP o SOAP).

Non è possibile trasferire le proprietà così come sono (coppie chiave-valore), ma possono essere passate assegnandole come valori di intestazioni dei messaggi in uscita (HTTP o SOAP). Tuttavia, è prerogativa del progettista del bridge assicurarsi che le intestazioni pertinenti, che possono essere usate dall'inoltro o dal servizio esterno, vengano passate.

Anche se è possibile usare le azioni route e di risposta per impostare le proprietà delle intestazione del messaggio, tenere conto di quanto segue:

  • Prestare attenzione all'uso delle intestazioni del messaggio SOAP To e ReplyTo, in quanto l'associazione sottostante, ad esempio le associazioni WCF, possono eseguire l'override di queste intestazioni del messaggio. Di conseguenza, se l'applicazione che usa questi messaggi precede le intestazioni del messaggio impostate tramite le azioni route o di risposta, potrebbe generare errori non previsti.

  • Non impostare intestazione SOAP MessageID quando i messaggi vengono instradati a endpoint che usano associazioni basicHttpBinding o basicHttpRelayBinding.

Vedere anche

Mostra:
© 2014 Microsoft