Considerazioni sui messaggi
BizTalk Server offre un ampio set di funzionalità per l'invio, la ricezione, la trasformazione e l'elaborazione dei messaggi. Alcune di queste funzionalità includono:
Possibilità di inviare e ricevere messaggi usando più trasporti standard del settore, ad esempio HTTP, SMTP, FTP/FTPS e WCF. Il supporto a livello di trasporto per l'invio e la ricezione dei messaggi viene eseguito usando adattatori BizTalk Server. L'integrazione dell'elaborazione di messaggi di BizTalk Server con varie applicazioni "line of business" (LOB) viene eseguita usando uno di molti acceleratori o adattatori BizTalk Server disponibili, ad esempio l'acceleratore BizTalk per HIPAA, BizTalk Accelerator for SWIFT o l'adapter SAP BizTalk. Questi acceleratori e adattatori sono conformi agli standard del settore, che a loro volta supportano un'integrazione semplice di BizTalk Server con sistemi conformi a specifici standard del settore.
Possibilità di elaborare più formati di messaggio, ad esempio testo normale, XML, binario e altri. Questa funzionalità è fondamentale per fornire l'integrazione di BizTalk Server con un ampio spettro di partner commerciali.
Supporto per la trasformazione dei messaggi o il mapping dei documenti. Il mapping supporta la trasformazione dei dati tra schemi diversi. Ad esempio, il mapping può essere usato per trasformare il contenuto di un ordine di acquisto cliente ricevuto in una ricevuta con notifica di spedizione da inviare al cliente.
BizTalk Server le orchestrazioni forniscono funzionalità per la creazione di processi aziendali che si estendono su tempo, organizzazioni, applicazioni e persone. BizTalk Server fornisce l'interfaccia grafica orchestrazione Designer per sviluppare processi aziendali che includono il supporto per le transazioni (sia il tipo MSDTC tradizionale che l'esecuzione prolungata), la gestione delle eccezioni, il debug, il rilevamento e l'estendibilità per la chiamata di codice esterno.
Nota
Vedere Ottimizzazione delle prestazioni dell'orchestrazione per informazioni sulle procedure consigliate da seguire quando si usano le orchestrazioni in BizTalk Server. Vedere l'argomento Creazione di orchestrazioni tramite orchestrazione Designer (https://go.microsoft.com/fwlink/?LinkId=158997) nella documentazione BizTalk Server per informazioni approfondite sull'uso della Designer orchestrazione.
La parte restante di questo argomento descrive le considerazioni sulle prestazioni relative alle dimensioni, alla complessità e al profilo di distribuzione dei messaggi elaborati in un ambiente BizTalk Server.
Considerazioni sulle dimensioni dei messaggi
Mentre BizTalk Server impone alcuna restrizione sulle dimensioni dei messaggi, i limiti pratici e le dipendenze potrebbero richiedere di ridurre al minimo le dimensioni dei messaggi perché i messaggi di grandi dimensioni richiedono più risorse di elaborazione. Quando le dimensioni dei messaggi aumentano, la velocità effettiva complessiva (messaggi elaborati al secondo) diminuisce. Quando si progetta lo scenario e la pianificazione per la capacità, prendere in considerazione le dimensioni medie dei messaggi, il tipo di messaggio e il numero di messaggi BizTalk Server processi. Non usare nomi di attributo e tag lunghi inutilmente lunghi; se possibile, mantenere la lunghezza inferiore a 50 caratteri. Ad esempio, non usare un nome di tag a 200 caratteri per una dimensione del messaggio di solo 1 byte.
Se le dimensioni in memoria di un messaggio ricevuto superano il numero di byte specificate per le dimensioni del frammento di messaggio di grandi dimensioni (configurabili nella pagina Proprietà gruppo per il gruppo BizTalk nella console di amministrazione BizTalk Server), il messaggio viene suddiviso in frammenti delle dimensioni specificate. Inoltre, i frammenti vengono scritti nella casella di messaggio nel contesto di una transazione Microsoft Distributed Transaction Coordinator (MSDTC) come indicato di seguito:
Se il messaggio in ingresso viene pubblicato nel contesto di una transazione MSDTC esistente, questa transazione viene usata durante la scrittura dei frammenti di messaggio nel database BizTalk MessageBox. Ad esempio, se il messaggio in ingresso viene pubblicato da una scheda transazionale configurata per richiedere transazioni, la transazione esistente verrà usata durante la scrittura dei frammenti di messaggio nel database MessageBox.
Se il messaggio in ingresso non viene pubblicato nel contesto di una transazione MSDTC esistente, viene creata una nuova transazione MSDTC per scrivere i frammenti di messaggio nel database MessageBox. In questo scenario si applicano le considerazioni seguenti:
Aumentare il valore per dimensioni del frammento di messaggi di grandi dimensioni per ridurre la frequenza con cui i messaggi di grandi dimensioni sono frammentati e ridurre l'incidenza della creazione delle transazioni MSDTC associate. L'uso eccessivo delle transazioni MSDTC è infatti onerosa dal punto di vista delle prestazioni. Se si aumenta questo valore è possibile che venga aumentata anche la quantità di memoria disponibile utilizzata.
Se richiede più tempo del timeout massimo consentito delle transazioni MSDTC di 60 minuti per scrivere un messaggio in MessageBox, il timeout della transazione, si verifica un errore e il tentativo di scrittura del messaggio ha esito negativo e viene eseguito il rollback. Il valore di dimensioni del frammento di messaggi di grandi dimensioni deve essere aumentato abbastanza per evitare questo problema durante l'elaborazione di messaggi molto grandi. A seconda della memoria disponibile, questo valore dovrà essere aumentato a un valore massimo pari a 1000000 byte.
Per ciascun frammento di messaggio in un messaggio viene creato uno o più blocchi di database SQL Server a fronte del database MessageBox. Quando il numero di blocchi supera diverse centinaia di migliaia, è possibile che SQL Server genererà errori di "out of lock". Se si verifica questo problema, aumentare il valore per dimensioni del frammento di messaggi di grandi dimensioni per ridurre il numero di frammenti (che riduce il numero di blocchi di database SQL Server effettuati sul database MessageBox) o valutare la possibilità di ospitare il database MessageBox in una versione a 64 bit di SQL Server. Il numero di blocchi disponibili è significativamente superiore alla versione a 64 bit di SQL Server rispetto a una versione a 32 bit di SQL Server. La formula seguente può essere usata per stimare il numero massimo di messaggi per interscambio quando il database MessageBox è ospitato in una versione a 32 bit di SQL Server:
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
Per altre informazioni su come BizTalk Server elabora messaggi di grandi dimensioni, incluse le linee guida per l'elaborazione di messaggi di grandi dimensioni, vedere How BizTalk Server Process Large Messages (https://go.microsoft.com/fwlink/?LinkID=154680).
Considerazioni sul tipo di messaggio
I messaggi vengono ricevuti in BizTalk Server in uno dei due formati principali: file XML o file flat. Il tipo di messaggio deve essere sempre inserito nel profilo di distribuzione dei messaggi a causa dei diversi requisiti di risorsa dei messaggi XML e flat.
File XML Affinché BizTalk Server eseguire qualsiasi elaborazione in un messaggio diverso dal routing pass-through, il messaggio deve essere nel formato di file XML.
File flat I file flat devono essere analizzati in un formato XML prima che BizTalk Server possa eseguire qualsiasi elaborazione diversa dal routing pass-through. L'analisi di un file flat in un file XML può aumentare notevolmente le dimensioni del file. I file flat non contengono tag XML con informazioni descrittive sui relativi dati. I file XML, d'altro canto, racchiudono tutti i dati in tag XML descrittivi. In alcuni scenari, l'analisi può aumentare le dimensioni di un file flat per un fattore pari a 10 o più, a seconda della quantità di dati descrittivi contenuti nei tag XML per il file.
Documenti file flat con wrapping in un singolo nodo di sezione CDATA in un documento XML Questo tipo di documento è una combinazione di file XML e flat ed è spesso intensivo per la memoria, poiché BizTalk Server deve caricare l'intero documento di file flat con wrapping nella memoria prima di elaborarlo.
Considerazioni sull'overload
La maggior parte delle applicazioni BizTalk Server non riceve messaggi a una frequenza specifica e costante. In genere, l'elaborazione dei messaggi è soggetta a picchi e valle. , ad esempio, un'applicazione online banking può elaborare un volume superiore di messaggi prima cosa al mattino, quindi durante la metà del giorno e alla fine del giorno. BizTalk Server soluzioni devono essere testate per garantire che possano gestire questi scenari di overload. Per determinare il modo in cui una soluzione BizTalk Server può gestire scenari di overload, è necessario determinare la velocità effettiva massima sostenibile (MST) della soluzione BizTalk Server. MST è il carico più alto del traffico di messaggi che un sistema può gestire in modo indefinito in un ambiente di produzione. Per altre informazioni su MST, vedere Pianificazione delle prestazioni sostenute (https://go.microsoft.com/fwlink/?LinkID=158065) e prestazioni sostenibili? (https://go.microsoft.com/fwlink/?LinkID=132304) nella documentazione di BizTalk Server.
Complessità dello schema
La velocità effettiva per l'analisi dei messaggi (in particolare l'analisi di file flat) è influenzata dalla complessità degli schemi. Quando la complessità dello schema aumenta, le prestazioni complessive diminuiscono. Quando si progettano schemi, ridurre la lunghezza dei nomi dei nodi e spostare le proprietà promosse nella parte superiore dello schema. Ciò riduce il tempo di recupero e aumenta così le prestazioni.
Complessità mappa
A seconda della complessità delle mappe, la trasformazione della mappa può essere a elevato utilizzo di risorse. Man mano che la complessità della mappa aumenta, le prestazioni complessive diminuiscono. Per migliorare le prestazioni complessive, ridurre al minimo il numero di collegamenti e functoid usati nelle mappe, in particolare functoid che chiamano risorse esterne, ad esempio il functoid Di ricerca del database.
Considerazioni sull'analisi di file flat
I due fattori che hanno l'impatto più elevato sulle prestazioni dell'analisi di file flat sono dimensioni e complessità dello schema. Uno schema ambiguo è uno schema che contiene molti campi facoltativi. Quando vengono usate dimensioni di file di grandi dimensioni, uno schema con molti campi facoltativi può ridurre le prestazioni perché i file più grandi possono corrispondere a rami diversi dello schema. La complessità dello schema ha un impatto minore sui file più piccoli rispetto ai file più grandi.