Elaborazione del messaggio
Tutti i componenti descritti fino a questo momento hanno un ruolo nell'elaborazione dei messaggi mentre passano attraverso BizTalk Server. In questa sezione vengono fornite ulteriori informazioni sul modo in cui questi componenti interagiscono dal punto di vista funzionale, a partire dalla ricezione di un messaggio. Nella figura seguente vengono illustrati la composizione di una porta di ricezione e il flusso di un messaggio attraverso il processo di ricezione.
Una porta di ricezione è costituita da uno o più indirizzi di ricezione e da zero o più mappe. Le mappe sono fogli di stile Extensible Stylesheet Language Transformations (XSLT) utilizzati per trasformare i messaggi XML da una struttura o formato in un altro e spesso sono utilizzate nel processo di ricezione per normalizzare i messaggi in un formato interno. Gli indirizzi di ricezione controllano gli endpoint che ricevono i messaggi. Un indirizzo di ricezione è costituito dalla configurazione di un endpoint per un adapter 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. L'adapter per file rileva, ad esempio, che un file è stato inserito nel suo indirizzo configurato e lo legge in un flusso. L'adapter crea un messaggio (un'implementazione dell'interfaccia Microsoft.BizTalk.Message.Interop.IBaseMessage), vi aggiunge una parte (un'implementazione dell'interfaccia Microsoft.BizTalk.Message.Interop.IBasePart) e fornisce il flusso di dati come contenuto della parte.
Inoltre scrive e alza di livello nel messaggio le proprietà del contesto relative all'indirizzo, al tipo di adapter e altre proprietà relative all'adapter. Dopo aver creato il messaggio e il suo contesto, l'adapter trasmette il messaggio a Gestione endpoint. Il messaggio viene quindi elaborato tramite la pipeline di ricezione che è stata configurata per l'indirizzo di ricezione. Dopo che la pipeline ha elaborato il messaggio, è possibile utilizzare una mappa per trasformare il messaggio nel formato desiderato prima che Gestione endpoint lo pubblichi con l'Agente messaggi.
Ruolo della pipeline
Anche se è l'adapter che crea il messaggio iniziale, la maggior parte dell'elaborazione che si verifica in un messaggio ricevuto ha luogo nella pipeline di ricezione. L'elaborazione della pipeline riguarda il contenuto del messaggio nonché il contesto del messaggio. Il contenuto del messaggio viene in genere gestito nelle fasi di decodifica, disassemblaggio e convalida, mentre il contesto del messaggio può essere gestito in tutte le fasi. Una pipeline non interviene però necessariamente sul contenuto o sul contesto. Nella pipeline predefinita di tipo pass-through, ad esempio, non vi sono componenti configurati e non viene eseguita alcuna elaborazione sul contenuto o sul contesto del messaggio. Per ragioni di semplicità, questo documento è incentrato sui componenti di disassemblaggio poiché in genere sono quelli che hanno il maggiore impatto sul routing dei messaggi.
Compito del disassembler è elaborare un messaggio proveniente da un adapter, disassemblarlo in molti messaggi e analizzare i dati del messaggio. Un messaggio in arrivo contenente numerosi messaggi più piccoli viene definito interscambio. Sia il disassembler file flat che il disassembler XML gestiscono gli interscambi consentendo a uno sviluppatore di configurare le informazioni sul contenuto di wrapping (ossia un'intestazione e uno schema finale per il disassembler file flat e uno schema di busta per il disassembler XML) e sul contenuto del corpo (potenzialmente ripetuto). Entrambi questi disassembler analizzano inoltre il messaggio originale nel contenuto XML. Un disassembler personalizzato non analizza necessariamente il contenuto in XML se in BizTalk Server non è richiesta un'ulteriore elaborazione XML. Uno scenario di esempio potrebbe includere una situazione semplice di routing in cui i messaggi che entrano nel sistema in un particolare indirizzo di ricezione vengono inviati a una porta di trasmissione specifica senza mapping o ulteriore elaborazione basata su XML.
Routing con il tipo di messaggio
Una delle proprietà dei messaggi più comuni utilizzate nel routing è il tipo di messaggio. Quando uno sviluppatore crea uno schema per definire la struttura di messaggi, questo schema definisce il tipo per quel messaggio. Il tipo viene determinato dal nodo principale 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 utilizzare il tipo di messaggio nel routing, deve essere innalzato di livello nel contesto. I disassembler sono utilizzati per innalzare di livello questo valore nel contesto del messaggio nonché i componenti della pipeline con la conoscenza più specifica della struttura del messaggio. I disassembler XML e File Flat innalzano di livello il tipo di messaggio mentre elaborano i messaggi e anche qualsiasi disassembler personalizzato dovrebbe innalzare questa proprietà per consentire il routing appropriato.
È importante notare che un messaggio non deve necessariamente avere un tipo. Come menzionato in precedenza, le parti di un messaggio possono essere costituite da qualsiasi dato binario e non devono avere necessariamente uno schema che definisce la loro struttura. Questo tipo di parte del messaggio viene in genere passato tramite BizTalk Server senza elaborazione o con poca elaborazione eseguita su di esso da parte di BizTalk Server, sebbene componenti della pipeline personalizzata, adapter o codice chiamato dalle orchestrazioni possano interagire con queste parti.
Componenti della pipeline come gli adapter consentono inoltre di scrivere e innalzare di livello le proprietà nel contesto del messaggio. I componenti della pipeline sono infatti il meccanismo più comune utilizzato dalla maggior parte degli sviluppatori per ottenere le proprietà nel contesto del messaggio. Gli sviluppatori creano gli schemi e possono innalzare di livello le proprietà nello schema. Queste informazioni vengono archiviate nello schema come annotazioni che possono essere poi utilizzate dai componenti della pipeline. Tutti i componenti incorporati del disassembler e dell'assembler, FlatFile, XML e BizTalk Framework, utilizzano lo schema del documento per recuperare le informazioni sulle proprietà che devono essere innalzate di livello. Utilizzando l'istruzione XPath (XML Path Language) dalle annotazioni, il disassembler conosce l'indirizzo nel documento degli elementi che devono essere innalzati di livello. Durante il processo di flusso attraverso il documento, il disassembler trova gli elementi che corrispondono a una delle istruzioni XPath e innalza di livello o scrive il valore nel contesto come appropriato.
È inoltre possibile gestire componenti della pipeline personalizzata per gestire l'ottenimento di proprietà nel contesto per i dati arbitrari in un messaggio ricevuto o inviato. Per innalzare di livello una proprietà nel contesto e fare in modo che sia utile per il routing, che probabilmente è il motivo per cui il valore viene innalzato di livello, è necessario creare uno schema proprietà con una definizione per la proprietà e distribuirlo a BizTalk Server. Prima di definire uno schema proprietà che possa essere utilizzato dai componenti personalizzati, è necessario capire i diversi tipi di proprietà innalzate di livello. Le proprietà innalzate di livello definite in uno schema proprietà possono avere uno di due tipi di base:
Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase
Una proprietà con un tipo di base di MessageDataPropertyBase indica che il valore per questa proprietà proviene dal contenuto del messaggio. Questo è il valore predefinito per le proprietà definite in uno schema proprietà ed è l'utilizzo più comune. MessageContextPropertyBase indica una proprietà destinata a far parte del contesto del messaggio ma che non proviene necessariamente direttamente dai dati del messaggio. Le proprietà con MessageContextPropertyBase come tipo di base vengono spesso innalzate di livello dagli adapter e dai disassembler e comprendono proprietà comuni quali tipo di messaggio e tipo di adapter.
Al momento di definire le proprietà è importante comprendere i diversi tipi e utilizzarli correttamente. Una delle implicazioni più significative si verifica quando si accede alle proprietà del contesto per un messaggio in un'orchestrazione. Se viene identificata una proprietà come MessageDataPropertyBase, Progettazione orchestrazioni esamina lo schema del messaggio ricevuto e assicura che definisca una proprietà innalzata di livello corrispondente. Se non viene trovata nessuna proprietà nello schema associato alla proprietà innalzata di livello a cui si accede, Progettazione orchestrazioni non consente di accedervi. D'altra parte, se la proprietà viene definita come MessageContextPropertyBase, il tipo di messaggio non è rilevante ed è possibile accedere alla proprietà.
Nelle pipeline personalizzate, il meccanismo di innalzamento del livello o di scrittura delle proprietà nel contesto è molto simile. Per scrivere le proprietà viene utilizzata una chiamata al metodo IBaseMessageContext.Write per inserire il valore nel contesto. Per le proprietà innalzate di livello viene invece utilizzato semplicemente il metodo IBaseMessageContext.Promote. Ognuno di questi metodi accetta un nome di proprietà, uno spazio dei nomi e un valore. Per le proprietà innalzate di livello, il nome e lo spazio dei nomi sono quelli della proprietà definita nello schema proprietà e sono più facilmente accessibili facendo riferimento all'assembly schema 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 usato come nome.Nel codice seguente viene illustrato un esempio di innalzamento di livello e di scrittura delle proprietà nel contesto. In questo esempio nel contesto viene scritto un campo differenziato. Ciò è utile solo per le orchestrazioni in cui lo schema messaggi identifica il campo differenziato affinché Progettazione orchestrazioni conosca il campo. Può essere utile scrivere le proprietà nel contesto che devono essere utilizzate da altri componenti della pipeline sul lato di ricezione o di trasmissione.
//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");
Quando si scrivono o si innalzano di livello valori nel contesto, tenere il presente quanto segue:
Se si scrive un valore nel contesto con lo stesso nome e spazio dei nomi utilizzati precedentemente per innalzare di livello la proprietà, quella proprietà non verrà più innalzata di livello. La scrittura sovrascrive essenzialmente l'innalzamento di livello.
Se si scrive un valore null nel contesto, il valore viene eliminato perché non sono consentite proprietà di valore null.
Le proprietà innalzate di livello sono limitate a 256 caratteri di lunghezza mentre le proprietà scritte non hanno alcuna limitazione di lunghezza.
Le proprietà innalzate di livello sono utilizzate nel routing dei messaggi e sono di dimensioni limitate per motivi di efficienza in termini di confronto e di memorizzazione. Mentre le proprietà scritte non hanno nessun limite rigido di dimensioni, l'utilizzo di valori troppo elevati nel contesto avrà un impatto sulle prestazioni poiché quei valori devono ancora essere elaborati e passati con il messaggio.
Quando un messaggio è pronto per essere inviato 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 per cliente o applicazione prima di essere elaborato dalla pipeline e di essere inviato attraverso l'adapter. Nella pipeline di trasmissione, le proprietà nel contesto del messaggio invece di essere innalzate di livello vengono abbassate dal contesto nel messaggio.
Vedere anche
Architettura di runtime
Modalità di elaborazione dei messaggi di grandi dimensioni in BizTalk Server