Ottimizzazione delle prestazioni di orchestrazione
In questo argomento vengono descritte le procedure consigliate per l'uso delle orchestrazioni nelle soluzioni BizTalk Server. Sono inclusi i suggerimenti per:
Riduzione della latenza delle soluzioni BizTalk Server che usano orchestrazioni
Eliminazione delle orchestrazioni solo per i modelli di messaggistica
Utilizzo di invii inline da orchestrazioni
Riduzione al minimo dei punti di persistenza dell'orchestrazione
Annidamento delle orchestrazioni
Modelli di progettazione dell'orchestrazione
Blocchi di gestione delle eccezioni di orchestrazione
Suggerimenti per l'ottimizzazione delle orchestrazioni per scenari a bassa latenza
Le tecniche seguenti possono essere usate per ridurre la latenza delle soluzioni BizTalk Server che usano orchestrazioni.
Eliminare le orchestrazioni solo per i modelli di messaggistica
Quando possibile, ridurre al minimo l'uso delle orchestrazioni per aumentare la velocità effettiva complessiva e ridurre la latenza dei processi aziendali. Se non è necessario eseguire transazioni a esecuzione prolungata e non è necessario richiamare più sistemi per ogni richiesta, valutare la possibilità di eliminare le orchestrazioni e spostare la logica di business in Porte di ricezione e trasmissione per ridurre la quantità totale di round trip in BizTalkMsgBoxDb e ridurre la latenza dovuta all'accesso al database. In questo caso, implementare pipeline personalizzate e riutilizzare le classi helper richiamate in precedenza dalle orchestrazioni. Usare le orchestrazioni solo quando è strettamente necessario per implementare modelli di progettazione come dispersione e raccogli o convoci. Per altre informazioni sui modelli di progettazione dell'orchestrazione, vedere l'argomento Implementazione di modelli di progettazione nelle orchestrazioni (https://go.microsoft.com/fwlink/?LinkId=140042) nella documentazione di BizTalk Server.
Usare gli invii inline dalle orchestrazioni per supportare scenari a bassa latenza
Quando possibile, ridurre al minimo l'uso delle orchestrazioni e favorire i modelli di solo messaggistica per aumentare la velocità effettiva complessiva e ridurre la latenza dei processi aziendali. Se non è necessario eseguire transazioni a esecuzione prolungata e non è necessario richiamare più sistemi, è consigliabile spostare la logica di business per ricevere e inviare porte ed eliminare l'uso di orchestrazioni. Questo approccio può essere implementato con pipeline personalizzate e che riutilizzano le classi helper richiamate in precedenza dalle orchestrazioni. Per ottenere prestazioni migliori in scenari a bassa latenza, adottare uno degli approcci seguenti:
Eliminare le orchestrazioni non necessarie e adottare modelli di sola messaggistica per ridurre la quantità totale di round trip al database BizTalk MessageBox. Questo approccio supporta una bassa latenza perché inline invia ignora il motore di messaggistica BizTalk e il sovraccarico associato. La funzionalità di invio inline dell'orchestrazione viene fornita con BizTalk Server 2006 e versioni successive.
All'interno delle orchestrazioni, eliminare le porte logiche associate alle porte fisiche e usare gli invii in linea al loro posto. Ad esempio, un invio inline può essere usato per creare un'istanza di una classe proxy WCF per richiamare un servizio Web downstream o un componente ADO.NET per accedere a un database di SQL Server. Nel diagramma seguente viene eseguito un invio inline quando l'orchestrazione crea un'istanza di un componente aziendale, che usa internamente un oggetto proxy WCF per richiamare direttamente un servizio Web downstream:
Nota
Anche se l'uso di invii inline dalle orchestrazioni riduce significativamente la latenza, esistono limitazioni per questo approccio. Poiché inline invia ignora il motore di messaggistica BizTalk, la funzionalità seguente fornita con il motore di messaggistica non è disponibile:
- Pipeline transazionali
- Pipeline reversibili
- Pipeline che chiamano l'API dell'intercettore BAM
- supporto dell'adattatore BizTalk Server
- Creazione di batch
- Tentativi
- Inizializzazione del set di correlazioni
- Configurazione dichiarativa
- Trasporti secondari
- Rilevamento
- Uso dichiarativo di BAM
Per altre informazioni sui tipi di pipeline che non possono essere eseguite dall'interno di un'orchestrazione, vedere la sezione "Restrizioni" dell'argomento How to Use Expressions to Execute Pipelines (https://go.microsoft.com/fwlink/?LinkId=158008) nella documentazione di BizTalk Server 2010.
Ottimizzare la latenza di orchestrazione riducendo il numero di punti di persistenza, se possibile
Un ambito di orchestrazione deve essere contrassegnato come "transazionale a esecuzione prolungata" solo se si desidera utilizzare timeout di compensazione o ambito. Un ambito transazionale a esecuzione prolungata causa un punto di persistenza aggiuntivo alla fine dell'ambito, pertanto devono essere evitati quando non è necessario usare timeout di compensazione o ambito. Un ambito atomico causa un punto di persistenza alla fine dell'ambito, ma garantisce anche che nessun punto di persistenza si verificherà all'interno dell'ambito atomico. Questo effetto collaterale di nessuna persistenza all'interno dell'ambito può talvolta essere usato per sfruttare i punti di persistenza batch (ad esempio quando si eseguono più invii). In generale, tuttavia, è consigliabile evitare ambiti atomici, se possibile. Il motore di orchestrazione salva in un archivio permanente l'intero stato di un'istanza di orchestrazione in esecuzione in vari punti, in modo che l'istanza possa essere ripristinata in un secondo momento in memoria ed eseguita fino al completamento. Il numero di punti di persistenza in un'orchestrazione è uno dei fattori chiave che influenzano la latenza dei messaggi che passano attraverso le orchestrazioni. Ogni volta che il motore raggiunge un punto di persistenza, lo stato interno di un'orchestrazione in esecuzione viene serializzato e salvato in MessageBox e questa operazione comporta un costo di latenza. La serializzazione dello stato interno include tutti i messaggi e le variabili di cui è stata creata un'istanza e non ancora rilasciate nell'orchestrazione. Maggiore è il numero di messaggi e variabili e maggiore sarà il numero di questi, maggiore sarà il tempo necessario per rendere persistente lo stato interno di un'orchestrazione. Un numero eccessivo di punti di persistenza può causare una riduzione significativa delle prestazioni. Per questo motivo, è consigliabile eliminare i punti di persistenza non necessari dalle orchestrazioni riducendo il numero di ambiti transazionali e Invia forme. Questo approccio consente di ridurre la contesa in MessageBox a causa della disidratazione e della riattivazione dell'orchestrazione, aumentando la scalabilità complessiva e riducendo la latenza di orchestrazione. Un altro consiglio è quello di mantenere sempre lo stato interno di un'orchestrazione il più piccolo possibile. Questa tecnica può ridurre significativamente il tempo impiegato dal motore XLANG serializzando, mantenendo e ripristinando lo stato interno di un'orchestrazione in caso di punto di persistenza. Un modo per ottenere questo risultato consiste nel creare variabili e messaggi il più tardi possibile e rilasciarli il prima possibile; Ad esempio, introducono ambiti non transazionali all'interno delle orchestrazioni e dichiarano variabili e messaggi all'interno di questi ambiti interni anziché dichiararli al livello più alto. Per altre informazioni sulla riduzione al minimo dei punti di persistenza dell'orchestrazione, vedere gli argomenti seguenti nella documentazione di BizTalk Server 2010:
Persistenza e motore di orchestrazione (https://go.microsoft.com/fwlink/?LinkID=155292).
Disidratazione e riattivazione dell'orchestrazione (https://go.microsoft.com/fwlink/?LinkID=155292).
Linee guida per l'uso di proprietà alzate di livello per accedere ai tag o agli attributi dei messaggi da un'orchestrazione
Se è necessario alzare di livello le proprietà, alzare di livello solo le proprietà usate per il routing dei messaggi, i filtri e la correlazione dei messaggi. L'innalzamento di ogni proprietà richiede che il componente disassembler (XML, Flat, custom) riconosca il tipo di documento e recuperi i dati dal messaggio usando l'espressione XPath dall'annotazione relativa contenuta nell'XSD che definisce il tipo di documento. Inoltre, ogni promozione di proprietà causa una chiamata separata della stored procedure bts_InsertProperty quando l'agente messaggi pubblica il messaggio nel database MessageBox. Se un'orchestrazione deve accedere a un particolare elemento o attributo contenuto in un documento XML, utilizzare una delle tecniche seguenti:
Ridurre il numero di proprietà scritte e promosse ed eliminare quelle che non sono strettamente necessarie.
Eliminare i campi distinti non necessari. I campi distinti sono proprietà di contesto scritte e possono occupare facilmente spazio significativo perché il nome è uguale all'espressione XPath usata per recuperare i dati. La proprietà distinguished viene definita come annotazioni nell'XSD che definisce il tipo di documento. Il componente disassembler usa lo stesso approccio adottato per le proprietà alzate di livello e usa l'espressione XPath che definisce un campo distinto per trovarlo all'interno del documento in ingresso. Il componente disassembler scrive quindi una proprietà nel contesto in cui:
Name: espressione XPath definita nell'annotazione.
Valore: valore dell'elemento identificato dall'espressione XPath all'interno di un documento in ingresso.
Le espressioni XPath possono essere molto lunghe, soprattutto quando l'elemento in questione è molto profondo nello schema del documento. Quindi, i campi più distinti, maggiore è la dimensione del contesto. Ciò a sua volta influisce negativamente sulle prestazioni complessive.
Usare la funzione predefinita XPath fornita dal runtime di orchestrazione.
Se i messaggi sono piuttosto piccoli (pochi kilobyte) e in formato XML, è possibile de-serializzare il messaggio in un'istanza della classe .NET e usare campi e proprietà pubblici. Se il messaggio richiede una elaborazione complessa (codice personalizzato, criteri del motore regole business e così via) che accedono ai dati usando le proprietà esposte da un'istanza di una classe .NET è molto più veloce usando le espressioni XPath. Al termine della logica di business richiamata dall'orchestrazione, l'oggetto entità può essere serializzato in un messaggio BizTalk. È possibile creare classi .NET da uno schema XML usando uno degli strumenti seguenti: strumento XSD (.NET Framework 2.0) o SVCUTIL (.NET Framework 3.0).
Abilitare un componente helper da un'orchestrazione. Questa tecnica presenta un vantaggio rispetto all'uso di campi distinti. In realtà, un'orchestrazione può leggere l'espressione XPath da un archivio di configurazione (file di configurazione, archivio di configurazione SSO, database personalizzato e così via), quindi, quando è necessario modificare l'espressione XPath, non è necessario modificare e ridistribuire uno schema, come è necessario fare per le proprietà alzate di livello e i campi distinti. Nell'esempio di codice seguente viene fornito un esempio di componente helper. Il componente usa la classe XPathReader fornita dal runtime BizTalk. In questo modo il codice può leggere il flusso del documento fino a quando non viene trovata l'espressione XPath.
#region Copyright
//===
//Microsoft Windows Server AppFabric Customer Advisory Team (CAT)
//
// This sample is supplemental to the technical guidance published on the community
// blog.
//
// Author: Paolo Salvatori.
//===
// Copyright © 2010 Microsoft Corporation. All rights reserved.
//
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOU BEAR THE RISK OF USING IT.
//===
#endregion
#region Using Directives
using System;
using System.Collections.Generic;
using System.IO;
using System.Xml;
using System.Linq;
using System.Text;
using System.Globalization;
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.Streaming;
using Microsoft.BizTalk.XPath;
#endregion
namespace Microsoft.AppFabric.CAT.Samples.DuplexMEP.Helpers
{
public class XPathHelper
{
#region Private Constants
private const string MessageCannotBeNull = "[XPathReader] The message cannot be null.";
#endregion
#region Public Static Methods
public static string GetValue(XLANGMessage message, int partIndex, string xpath)
{
try
{
if (message == null)
{
throw new ApplicationException(MessageCannotBeNull);
}
using (Stream stream = message[partIndex].RetrieveAs(typeof(Stream)) as Stream)
{
XmlTextReader xmlTextReader = new XmlTextReader(stream);
XPathCollection xPathCollection = new XPathCollection();
XPathReader xPathReader = new XPathReader(xmlTextReader, xPathCollection);
xPathCollection.Add(xpath);
while (xPathReader.Read())
{
if (xPathReader.HasAttributes)
{
for (int i = 0; i < xPathReader.AttributeCount; i++)
{
xPathReader.MoveToAttribute(i);
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.GetAttribute(i);
}
}
}
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.ReadString();
}
}
}
}
finally
{
message.Dispose();
}
return string.Empty;
}
#endregion
}
}
Ridurre al minimo la complessità dell'orchestrazione per migliorare le prestazioni
La complessità delle orchestrazioni ha un impatto significativo sulle prestazioni. Man mano che aumenta la complessità dell'orchestrazione, le prestazioni complessive diminuiscono. Le orchestrazioni possono essere usate in una varietà quasi infinita di scenari e ogni scenario può comportare orchestrazioni di complessità variabile. Evitare orchestrazioni complesse, se possibile, a favore di un approccio modulare. In altre parole, suddividere la logica di business in più orchestrazioni riutilizzabili.
Se è necessario implementare un'orchestrazione complessa, definire messaggi e variabili in ambiti interni, quando possibile anziché a livello radice. Questa tecnica mantiene un footprint più piccolo in memoria per ogni orchestrazione perché le variabili e i messaggi vengono eliminati quando il flusso lascia l'ambito in cui sono state definite le variabili e i messaggi. Questo approccio è particolarmente utile quando le orchestrazioni vengono salvate in MessageBox in punti di persistenza.
Usare la forma Orchestrazione chiamate rispetto alla forma Avvia orchestrazione per migliorare le prestazioni
Evitare la forma Avvia orchestrazione e utilizzare la forma Orchestrazione chiamate per eseguire un'orchestrazione annidata. In effetti, la forma Orchestrazione chiamate può essere usata per chiamare in modo sincrono un'orchestrazione a cui si fa riferimento in un altro progetto. Questo approccio consente di riutilizzare i modelli comuni del flusso di lavoro di orchestrazione nei progetti BizTalk. Quando si richiama un'altra orchestrazione annidata in modo sincrono con la forma Orchestrazione chiamate , l'orchestrazione che racchiude attende il completamento dell'orchestrazione annidata prima di continuare. L'orchestrazione annidata viene eseguita nello stesso thread che esegue l'orchestrazione chiamante.
La forma Avvia orchestrazione è simile alla forma Orchestrazione chiamate , ma in questo caso l'orchestrazione annidata viene chiamata in modo asincrono: il flusso di controllo nella chiamata dell'orchestrazione procede oltre la chiamata, senza attendere che l'orchestrazione richiamata finisca il lavoro. Per implementare questo disaccoppiamento tra il chiamante e le orchestrazioni chiamate, l'orchestrazione di avvio viene implementata tramite pubblicazione di un messaggio nella casella di messaggio BizTalk. Questo messaggio viene quindi utilizzato da un'istanza host BizTalk in-process che esegue l'orchestrazione annidata. Quando possibile, usare Orchestrazione chiamate, soprattutto se l'orchestrazione chiamante deve attendere un risultato dall'orchestrazione annidata per continuare l'elaborazione. Per altre informazioni sull'uso della forma Orchestrazione chiamate, vedere gli argomenti seguenti nella documentazione di BizTalk Server 2010:
Uso delle porte associate dirette nelle orchestrazioni (https://go.microsoft.com/fwlink/?LinkId=139902).
Annidamento di orchestrazioni (https://go.microsoft.com/fwlink/?LinkId=139903).
Usare XmlReader con XLANGMessage rispetto all'uso di XmlReader con XmlDocument per migliorare le prestazioni di orchestrazione
Per migliorare le prestazioni di orchestrazione per i metodi .NET chiamati da un'orchestrazione, usare XmlReader con XLANGMessage, non XmlDocument. Nell'esempio di codice seguente viene illustrata questa funzionalità.
// As a general rule, use XmlReader with XLANGMessage, not XmlDocument.
// This is illustrated in the parameter passed into the following code.
// The XLANG/s compiler doesn't allow a return value of XmlReader
// so documents must be initially constructed as XmlDocument()
public static XmlDocument FromMsg(XLANGMessage old)
{
//get at the data
XmlDocument ret = new XmlDocument();
try{
XmlReader reader = (XmlReader)old[0].RetrieveAs(typeof(XmlReader));
//construct new message from old
//read property
object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
}
finally {
// Call Dispose on the XLANGMessage object
// because the message doesn't belong to the
// .NET runtime - it belongs to the Messagebox database
old.Dispose();
}
return ret;
}
Un altro metodo consiste nel creare una classe .NET basata sullo schema. Questa operazione richiede meno memoria del caricamento del documento in un oggetto XmlDocument , oltre a fornire un facile accesso agli elementi dello schema per gli sviluppatori .NET. Per generare una classe basata su uno schema BizTalk, è possibile usare lo strumento xsd.exe fornito con Visual Studio. Ad esempio, l'esecuzione dixsd.exe <schema.xsd> /classe su uno schema semplice contenente campi denominati ItemA, ItemB, ItemC, produrrà la classe seguente.
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.1433
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
using System.Xml.Serialization;
//
// This source code was auto-generated by xsd, Version=2.0.50727.42.
//
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="http://Schemas.MySchema")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="http://Schemas.MySchema", IsNullable=false)]
public partial class MySchemaRoot {
private string itemAField;
private string itemBField;
private string itemCField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string ItemA {
get {
return this.itemAField;
}
set {
this.itemAField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string ItemB {
get {
return this.itemBField;
}
set {
this.itemBField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string ItemC {
get {
return this.itemCField;
}
set {
this.itemCField = value;
}
}
}
È quindi possibile fare riferimento a questa classe nell'assembly .NET per accedere agli elementi del messaggio e l'oggetto restituito può essere assegnato direttamente a un messaggio. Di seguito è riportato un esempio di utilizzo della classe generata in precedenza.
public static Root SetValues(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)
{
try
{
MySchemaRoot rootObj=(MySchemaRoot)msg[0].RetrieveAs(typeof(MySchemaRoot);
rootObj.ItemA="value a";
rootObj.ItemB="value b";
rootObj.ItemC="value c";
}
finally {
msg.Dispose();
}
return rootObj;
}
Questa tecnica consente di usare un approccio orientato agli oggetti durante l'elaborazione dei messaggi. Questa tecnica deve essere usata principalmente con messaggi relativamente piccoli. Ciò è dovuto al fatto che anche se questa tecnica usa molto meno memoria rispetto al caricamento del messaggio in un oggetto XmlDocument , l'intero messaggio viene ancora caricato in memoria. Quando si elaborano messaggi di dimensioni maggiori, utilizzare la classe XmlReader per leggere i messaggi e la classe XmlWriter per scrivere messaggi. Quando si utilizza XmlReader e XmlWriter, il messaggio è contenuto in un oggetto VirtualStream . Se la dimensione del messaggio supera il valore specificato per soglia messaggi di grandi dimensioni (byte) esposta nella pagina di configurazione Proprietà gruppo BizTalk, il messaggio viene scritto nel file system. Ciò riduce le prestazioni complessive, ma evita eccezioni di memoria insufficiente.
Migliorare le prestazioni riducendo al minimo l'uso di porte logiche associate alle porte fisiche
È possibile aumentare le prestazioni riducendo al minimo l'uso di porte logiche associate a porte fisiche che usano le schede seguenti:
SQL Server, Oracle
WSE, HTTP, WCF
MSMQ, MQSeries
In BizTalk Server 2010 le pipeline di invio e ricezione possono essere richiamate direttamente da un'orchestrazione usando la classe XLANGPipelineManager contenuta nel Microsoft.XLANGs.Pipeline.dll. Di conseguenza, l'elaborazione delle pipeline può essere spostata dalle porte alle orchestrazioni; le porte logiche in un'orchestrazione possono essere sostituite con una forma Expression, che richiama un'istanza di una determinata classe .NET, ad esempio un componente di Accesso ai dati tramite ADO.NET. Prima di adottare questa tecnica, è necessario tenere presente che, se non si usano schede e porte fisiche, si perde la possibilità di sfruttare le funzioni, ad esempio batch, tentativi, configurazione dichiarativa e trasporti secondari.
Modelli di progettazione dell'orchestrazione
L'orchestrazione Designer consente agli sviluppatori di implementare un'ampia gamma di modelli di integrazione aziendale. Alcuni modelli comuni includono Aggregator, Gestione delle eccezioni e Compensazione, Broker messaggi, Dispersione e Gather eVoy sequenziale e parallelo. Questi modelli possono essere usati per sviluppare soluzioni EAI (Enterprise Application Integration), Service-Oriented Architecture (SOA) e Business Process Management (BPM) con BizTalk Server. Per altre informazioni sui modelli di progettazione dell'orchestrazione, vedere l'argomento Implementazione di modelli di progettazione nelle orchestrazioni (https://go.microsoft.com/fwlink/?LinkId=140042) nella documentazione di BizTalk Server e modelli e procedure consigliate per l'integrazione aziendale (https://go.microsoft.com/fwlink/?LinkId=140043).
Usare le classi .NET appropriate nelle orchestrazioni per ottimizzare le prestazioni
In generale, le classi .NET usate all'interno di un'orchestrazione possono essere suddivise in due categorie distinte:
Helper e servizi - Queste classi forniscono servizi comuni per orchestrazioni, ad esempio traccia, gestione degli errori, memorizzazione nella cache e serializzazione/deserializzazione. La maggior parte di queste classi può essere implementata come classi statiche senza stato interno e più metodi statici pubblici. Questo approccio evita la creazione di più oggetti della stessa classe in orchestrazioni diverse in esecuzione contemporaneamente, in modo da ridurre lo spazio di lavoro dei processi host e risparmiare memoria. Una classe senza stato consente di ridurre le dimensioni complessive dello stato interno che devono essere serializzate e rese persistenti in BizTalk MessageBox quando un'orchestrazione viene disidratata.
Entità e oggetti business - È possibile usare queste classi per gestire entità, ad esempio ordini, articoli di ordine e clienti. Una singola orchestrazione può creare e gestire internamente più istanze dello stesso tipo. Queste classi sono in genere con stato ed espongono campi pubblici e/o proprietà insieme ai metodi per modificare lo stato interno dell'oggetto. Le istanze di queste classi possono essere create dinamicamente deserializzando una parte XLANGMessage in un oggetto .NET usando le classi XmlSerializer o DataContractSerializer o tramite il metodo XLANGPart.RetrieveAs . È consigliabile strutturare un'orchestrazione usando ambiti non transazionali in modo che le istanze delle classi con stato vengano create il più tardi possibile e rilasciate non appena non sono più necessarie. Questo approccio riduce lo spazio di lavoro dei processi host e riduce al minimo le dimensioni complessive dello stato interno serializzato e persistente nel database MessageBox quando un'orchestrazione viene disidratata. Per altre informazioni sull'uso delle orchestrazioni in BizTalk Server, vedere l'articolo Domande frequenti sulle orchestrazioni BizTalk Server (https://go.microsoft.com/fwlink/?LinkID=116886).
Nota
Anche se questo articolo è scritto per BizTalk Server 2004 e BizTalk Server 2006, i concetti presentati si applicano anche alle orchestrazioni BizTalk Server 2010.
Blocchi del gestore di eccezioni di orchestrazione
Quando si usano blocchi del gestore eccezioni di orchestrazione, includere tutte le forme di orchestrazione in uno o più ambiti (ambiti non transazionali quando possibile) e creare almeno i blocchi del gestore eccezioni seguenti:
Blocco del gestore eccezioni per la gestione di un errore System.Exception generico.
Blocco del gestore eccezioni per la gestione di un'eccezione generale per rilevare e gestire possibili errori non gestiti, ad esempio eccezioni COM.
Per altre informazioni sull'uso dei blocchi di gestione delle eccezioni di orchestrazione, vedere gli articoli seguenti:
Uso di BizTalk Server gestione delle eccezioni (https://msdn.microsoft.com/library/aa561229.aspx).
Charles Young Blog, BizTalk Server 2006: The Compensation Model (https://go.microsoft.com/fwlink/?LinkId=158017).
Nota
Anche se questo blog è stato scritto con BizTalk Server 2006 in mente, i principi descritti nel blog si applicano anche a BizTalk Server.
Considerazioni sull'uso delle mappe nelle orchestrazioni
Quando si usano le mappe nelle orchestrazioni, si applicano le considerazioni seguenti:
Se si usa una mappa per estrarre o impostare proprietà usate con la logica di business in un'orchestrazione, usare campi distinti o proprietà alzate di livello. Questa procedura deve essere seguita perché quando si estraggono o impostano valori con una mappa il documento viene caricato in memoria, tuttavia quando si usano campi distinti o proprietà alzate di livello, il motore di orchestrazione accede al contesto del messaggio e non carica il documento in memoria.
Se si utilizza una mappa per aggregare più campi in un solo campo, utilizzare campi differenzianti o proprietà innalzate di livello con una variabile dell'orchestrazione per accumulare il set di risultati.