Elaborazione del messaggio

Tutti i componenti descritti finora svolgono un ruolo nell'elaborazione dei messaggi durante il flusso attraverso BizTalk Server. In questa sezione vengono fornite informazioni più dettagliate sul modo in cui questi componenti interagiscono in modo funzionale, a partire dalla ricezione di un messaggio. Nella figura seguente viene illustrato il make-up di una porta di ricezione e il flusso di un messaggio attraverso il processo di ricezione.

Una porta di ricezione è costituita da una o più posizioni di ricezione e zero o più mappe. Le mappe sono fogli di stile XSLT (Extensible Stylesheet Language Transformations) utilizzati per trasformare i messaggi XML da una struttura o formato a un altro e vengono spesso utilizzati nel processo di ricezione per normalizzare i messaggi in un formato interno. I punti di ricezione controllano gli endpoint che ricevono i messaggi. Un percorso di ricezione è costituito dalla configurazione di un endpoint per un adattatore di ricezione e da una pipeline di ricezione.

Ruolo dell'adapter

L'adapter di ricezione avvia il processo di ricezione dei messaggi leggendo un flusso di dati e creando un messaggio. Ad esempio, l'adattatore file rileva che un file è stato inserito nel percorso configurato e legge tale file in un flusso. L'adattatore crea un messaggio (un'implementazione dell'interfaccia Microsoft.BizTalk.Message.Interop.IBaseMessage), aggiunge una parte (un'implementazione dell'interfaccia Microsoft.BizTalk.Message.Interop.IBasePart) e fornisce il flusso di dati come parte del contenuto.

Inoltre, l'adattatore scrive e spinge nelle proprietà del contesto del messaggio informazioni correlate al percorso, al tipo di adattatore e ad altri aspetti correlati. Dopo aver creato il messaggio e il relativo contesto, l'adapter passa il messaggio a Endpoint Manager. Il messaggio viene quindi elaborato tramite la pipeline di ricezione, che è stata configurata per il percorso di ricezione. Dopo che il messaggio è stato elaborato dalla pipeline, è possibile usare una mappa per trasformare il messaggio nel formato desiderato prima che Endpoint Manager pubblica il messaggio con l'agente messaggi.

Ruolo della pipeline

Mentre si tratta dell'adapter che crea il messaggio iniziale, la maggior parte dell'elaborazione che si verifica in un messaggio ricevuto avviene nella pipeline di ricezione. L'elaborazione della pipeline gestisce il contenuto dei messaggi e il contesto del messaggio. Il contenuto del messaggio viene generalmente gestito nelle fasi di decodifica, disassembling e convalida, mentre il contesto del messaggio può essere gestito in tutte le fasi. Tuttavia, una pipeline non agisce necessariamente né sul contenuto né sul contesto. Ad esempio, la pipeline pass-through predefinita non ha componenti configurati e non esegue alcuna elaborazione sul contenuto o sul contesto del messaggio. Per semplicità, questo documento è incentrato sui componenti di disassembling, in quanto in genere hanno il maggiore impatto sul routing dei messaggi.

Il processo del disassembler consiste nell'elaborare un messaggio in arrivo da un adattatore e disassemblarlo in molti messaggi e analizzare i dati del messaggio. Quando un messaggio in arrivo contiene molti messaggi più piccoli, questo tipo di interscambio è noto come interscambio. Sia il disassemblatore di file flat che il disassemblatore XML gestiscono gli interscambi consentendo agli sviluppatori di configurare le informazioni sul contenuto avvolgente (cioè un'intestazione e uno schema finale per il disassemblatore di file flat e uno schema a busta per il disassemblatore XML) e il contenuto del corpo (potenzialmente ripetitivo). Inoltre, entrambi questi disassembler analizzano il messaggio originale in contenuto XML. Un disassembler personalizzato non analizza necessariamente il contenuto in XML se non è necessaria un'ulteriore elaborazione XML in BizTalk Server. Uno scenario di esempio può includere una semplice situazione di routing in cui i messaggi che entrano nel sistema in una determinata posizione di ricezione vengono inviati a una porta di trasmissione specifica senza mapping o altre elaborazioni basate su XML.

Routing con il tipo di messaggio

Una delle proprietà di messaggio più comuni usate nel routing è il tipo di messaggio. Quando uno sviluppatore crea uno schema per definire la struttura dei messaggi, questo schema definisce il tipo di messaggio per tale messaggio. Il tipo è determinato dal nodo radice e dallo spazio dei nomi nella definizione dello schema. Ad esempio, un documento XML simile al seguente avrà un tipo di messaggio http://tempuri.org/samples/MessageType#Message

<Message xmlns=http://tempuri.org/samples/MessageType>  
<SomeOtherElement type="sample"/>  
</Message>  

Per usare il tipo di messaggio nel routing, è necessario alzarlo di livello nel contesto. I disassembler vengono usati per promuovere questo valore nel contesto del messaggio, nonché nei componenti della pipeline con la conoscenza più specifica della struttura dei messaggi. I disassembler XML e Flat File alzano di livello il tipo di messaggio durante l'elaborazione dei messaggi e qualsiasi disassembler personalizzato deve alzare di livello questa proprietà per garantire il routing corretto.

È importante notare che un messaggio non deve avere un tipo. Come accennato in precedenza, le parti di un messaggio possono essere dati binari e non devono avere uno schema che ne definisce la struttura. Questo tipo di parte del messaggio viene in genere passato attraverso BizTalk Server senza che vi sia, o solo limitata, elaborazione da parte di BizTalk Server stesso, anche se componenti personalizzati della pipeline, adattatori o codice chiamati dalle orchestrazioni possono interagire con esse.

I componenti della pipeline, come gli adattatori, scrivono e promuovono le proprietà nel contesto del messaggio. Infatti, i componenti della pipeline sono il meccanismo più comune usato dalla maggior parte degli sviluppatori per ottenere le proprietà nel contesto del messaggio. Gli sviluppatori creano schemi e possono alzare di livello le proprietà nello schema. Queste informazioni vengono archiviate nello schema come annotazioni che possono quindi essere usate dai componenti della pipeline. Tutti i componenti del disassembler e dell'assembler predefiniti, FlatFile, XML e BizTalk Framework, usano lo schema del documento per recuperare informazioni sulle proprietà che devono essere promosse. Usando l'istruzione XPath (XML Path Language) delle annotazioni, il disassembler conosce la posizione nel documento degli elementi da promuovere. Durante il processo di streaming attraverso il documento, il disassembler trova gli elementi che corrispondono a una delle istruzioni XPath e promuove o scrive il valore nel contesto in base alle esigenze.

I componenti della pipeline personalizzati possono essere creati anche per gestire il processo di recupero delle proprietà nel contesto dei dati arbitrari in un messaggio ricevuto o inviato. Per alzare di livello una proprietà nel contesto e renderla utile per il routing, che è presumibilmente il motivo per cui il valore viene alzato di livello, è necessario creare e distribuire uno schema di proprietà con una definizione per la proprietà in BizTalk Server. Prima di definire uno schema di proprietà da usare dai componenti personalizzati, è necessario comprendere i diversi tipi di proprietà alzate di livello. Le proprietà promosse definite in uno schema di proprietà possono avere uno dei seguenti due tipi di base:

• Microsoft.XLANGs.BaseTypes.MessageContextPropertyBase o

• Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase

  Una proprietà con un tipo di base MessageDataPropertyBase indica che il valore di questa proprietà proviene dal contenuto del messaggio. Si tratta del valore predefinito per le proprietà definite in uno schema di proprietà ed è l'utilizzo più comune. MessageContextPropertyBase indica una proprietà che deve far parte del contesto del messaggio, ma non necessariamente proviene direttamente dai dati del messaggio. Le proprietà con MessageContextPropertyBase come tipo di base vengono spesso promosse da adapter e disassembler e includono proprietà comuni, ad esempio tipo di messaggio e tipo di adattatore.

  È importante comprendere i diversi tipi e usarli in modo appropriato quando si definiscono le proprietà. Una delle implicazioni più significative si verifica quando si accede alle proprietà del contesto per un messaggio in un'orchestrazione. Se una proprietà viene identificata come il MessageDataPropertyBase, Orchestration Designer esamina lo schema del messaggio ricevuto e si assicura che definisca una proprietà promossa corrispondente. Se nello schema non viene trovata alcuna proprietà associata alla proprietà promossa a cui si sta cercando di accedere, il Designer non consente di accedervi. D'altra parte, se la proprietà è definita come MessageContextPropertyBase, il tipo di messaggio non è rilevante e la proprietà può essere accessibile.

  Nelle pipeline personalizzate, il meccanismo per promuovere o scrivere proprietà nel contesto è molto simile. Per la scrittura di proprietà, usare una chiamata al metodo IBaseMessageContext Write per inserire il valore nel contesto. Per le proprietà alzate di livello, è sufficiente usare il metodo IBaseMessageContext Promote. Ognuno di questi metodi accetta un nome di proprietà, uno spazio dei nomi e un valore. Per le proprietà promosse, il nome e lo spazio dei nomi sono quelli della proprietà definita nello schema delle proprietà e sono più facilmente accessibili riferendosi all'assembly dello schema delle proprietà e utilizzando le proprietà nella classe creata per la proprietà. I campi distinti usano uno spazio dei nomi comune, http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFieldse l'espressione XPath usata per recuperare il valore viene in genere usata come nome.

  Il codice seguente mostra un esempio di promozione e scrittura di proprietà nel contesto. Si noti che in questo esempio viene scritto un campo distinto nel contesto. Ciò è utile solo per le orchestrazioni in cui lo schema del messaggio identifica il campo distinto in modo che Orchestration Designer conosca il campo. Può essere utile scrivere proprietà nel contesto per l'uso da parte di altri componenti della pipeline sul lato ricevente o di invio.

//create an instance of the property to be promoted  
SOAP.MethodName methodName = new SOAP.MethodName();  
  
//call the promote method on the context using the property class for name   
//and namespace  
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,   
"theSOAPMethodName");  
  
//write a distinguished field to the context  
pInMsg.Context.Write("theDistinguishedProperty",   
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",   
"theDistinguishedValue");  

Tenere presenti i fatti seguenti durante la scrittura o la promozione di valori nel contesto:

• La scrittura di un valore nel contesto con lo stesso nome e lo stesso spazio dei nomi utilizzati in precedenza per promuovere la proprietà fa sì che tale proprietà non venga più promossa. Il processo di scrittura sovrascrive essenzialmente la promozione.

• La scrittura di un valore null nel contesto elimina il valore, perché le proprietà con valori Null non sono consentite.

• Le proprietà alzate di livello sono limitate a 256 caratteri, mentre le proprietà scritte non presentano limitazioni di lunghezza.

  Le proprietà promosse vengono utilizzate nel routing dei messaggi, e le dimensioni sono limitate sia per motivi di efficienza nel confronto, sia nell'archiviazione. Anche se le proprietà scritte non hanno limiti rigidi sulle dimensioni, l'uso di valori eccessivamente grandi nel contesto avrà un impatto sulle prestazioni, perché tali valori devono essere comunque elaborati e passati con il messaggio.

  Quando un messaggio è pronto per l'invio da BizTalk Server, viene sottoposto a un processo complementare nella porta di trasmissione. Le mappe vengono applicate ai messaggi prima dell'esecuzione della pipeline di trasmissione, consentendo la trasformazione di un messaggio in un formato specifico del cliente o dell'applicazione prima di essere elaborato dalla pipeline e inviato tramite l'adapter. Nella pipeline di invio, invece di promuovere le proprietà nel contesto del messaggio, le proprietà vengono declassate dal contesto al messaggio.

  

Vedere anche

Architettura di runtime
Come BizTalk Server elabora messaggi di grandi dimensioni