Elaborazione nell'orchestrazione OrderBroker
Questa sezione descrive come l'orchestrazione OrderBroker accetta gli ordini e li prepara per un gestore di processi. All'inizio della sezione viene esaminato il funzionamento generale dell'orchestrazione. Nella parte successiva viene illustrato il modo in cui un messaggio viene elaborato dall'orchestrazione. Viene quindi evidenziato il modo in cui l'orchestrazione utilizza una transazione atomica per migliorare le prestazioni.
Nota
A causa della lunghezza del codice OrderBroker , è possibile leggere questa sezione con l'orchestrazione aperta in Microsoft® Visual Studio.
Scopo dell'intermediazione degli ordini
Lo scopo dell'orchestrazione OrderBroker è quello di pre-elaborare un ordine e di instradarlo al gestore di processi corretto. In questo caso, la pre-elaborazione consiste nella creazione di messaggi informativi per il database della cronologia e per il sistema di manutenzione e nella conferma della ricezione dell'ordine. OrderBroker crea anche un messaggio di ordine generico dalla richiesta del servizio clienti. Questa normalizzazione dell'ordine consente l'utilizzo generico dell'ordine da parte degli elementi del processo di business.
Il messaggio di ordine è un messaggio multiparte con informazioni di routing distinte dalle informazioni dell'ordine. Anche le informazioni di routing sono generiche e sono destinate all'utilizzo da parte di un gestore di ordini. Ciò contribuisce a semplificare l'espansione della soluzione. Per informazioni sui messaggi in più parti, vedere Come usare tipi di messaggi in più parti.
L'isolamento della funzione di brokering consente inoltre lo spostamento in un altro gruppo BizTalk. Poiché OrderBroker pubblica nel database MessageBox, ovvero è associato direttamente, rende più semplice inserire il broker in un altro gruppo, ma è possibile spostare il broker senza modificare l'orchestrazione. Per altre informazioni sull'inserimento di OrderBroker in un altro gruppo, vedere Comunicazione tra OrderBroker e OrderManager.
Nota
L'orchestrazione OrderBroker , perché ha un solo OrderManager con cui comunicare, assegna semplicemente una stringa costante al campo OrderMgrType nel messaggio di gestione ordini. In genere, in un'applicazione in cui sono presenti più gestori di ordini, l'applicazione utilizza il Motore regole di business per determinare il valore appropriato per questo campo e per il routing dell'ordine. Per altre informazioni sul motore regole business, vedere Creazione e utilizzo di regole business.
Elaborazione degli ordini
L'orchestrazione OrderBroker inizia con due forme Receive all'interno di una forma Listen . Una forma Receive prende i messaggi dal sistema di supporto clienti; l'altro, i messaggi del sistema fornitore. I messaggi provenienti da entrambe le origini hanno lo stesso schema.
L'orchestrazione estrae l'indirizzo restituito dal messaggio e lo usa per impostare l'indirizzo per la porta dinamica CSRPort. L'orchestrazione utilizza questa porta per inviare messaggi di riconoscimento e di errore.
I passaggi successivi dell'orchestrazione OrderBroker creano il messaggio di cronologia, il messaggio del servizio, il messaggio di conferma e il messaggio di ordine da inviare all'orchestrazione OrderManager . L'orchestrazione usa la funzione di utilità InsertOrderBody per aggiungere il messaggio di ordine al messaggio di cronologia.
Nota
In alcune situazioni è possibile che la soluzione produca messaggi che vengono recapitati ma non utilizzati. L'orchestrazione di intermediazione degli ordini utilizza una porta di trasmissione per inserire informazioni nel database della cronologia. Questa porta di trasmissione utilizza la notifica di recapito. La configurazione esegue il mapping della porta di trasmissione a un gruppo di porte di trasmissione contenente due porte, una per la configurazione di test (HistoryInsert-Test-SP), una per la configurazione regolare (HistoryInsert-SP). Se si lasciano in esecuzione entrambe le porte del gruppo, la soluzione invia messaggi su entrambe. Vengono pertanto richieste due notifiche di recapito, ma ne viene elaborata una sola.
Per evitare questa situazione, annullare l'elenco della porta di test (HistoryInsert-Test-SP) o arrestare la versione di test dell'applicazione , BTSScn.BPM.OrderBrokerApp.Test. Per altre informazioni sulle notifiche di recapito, vedere Uso dei riconoscimenti.
Quando si costruisce il messaggio da inviare all'orchestrazione OrderManager , l'orchestrazione OrderBroker crea un messaggio in più parti con due parti. Una parte contiene le informazioni di routing, l'altra le informazioni relative all'ordine stesso. La parte di routing del messaggio OrderMgrMsg.Routing usa uno schema definito da una classe C# nell'assembly SchemaClasses . Il broker considera la parte dell'ordine del messaggio come un documento XML generico o indipendente dal tipo (System.Xml. XmlDocument) e lo assegna a OrderMgrMsg.Order.
Esistono due campi nelle informazioni di routing particolarmente importanti per il gestore degli ordini, OrderMgrMsg.Routing.OrderMgrType e OrderMgrMsg.Routing.Status. Il broker imposta OrderMgrType sul tipo di gestore ordini che deve gestire l'ordine. Nella soluzione è presente un solo gestore di ordini e il campo viene impostato su CABLEORDER. Il broker imposta anche il campo Status su ACCEPTED. Questo valore indica al gestore di ordini che il messaggio è un nuovo ordine. Il gestore degli ordini nella soluzione, l'orchestrazione OrderManager , usa una forma Receive che filtra per il tipo di ordine uguale a CABLEORDER e lo stato uguale a ACCEPTED.
I passaggi rimanenti nell'orchestrazione OrderBroker inviano i diversi messaggi alle porte appropriate.
Miglioramento delle prestazioni con ambiti annidati
Uno degli aspetti evidenti dell'orchestrazione OrderBroker è l'uso di ambiti annidati. Una delle funzioni degli ambiti annidati consiste nel migliorare le prestazioni tramite la limitazione dei punti di persistenza.
Il motore di orchestrazione salva periodicamente lo stato dell'intera orchestrazione in corrispondenza dei punti di esecuzione denominati punti di persistenza. Il motore di orchestrazione considera automaticamente diverse forme di orchestrazione, tra cui Send shapes, come punti di persistenza. Per un elenco dei punti di persistenza e altre informazioni su di essi, vedere Persistenza e motore di orchestrazione.
Con cinque forme Send , l'orchestrazione OrderBroker deve avere cinque punti di persistenza. Tuttavia, quando si raggruppaNo forme all'interno di un ambito di transazione atomica, il motore lo riconosce solo per un punto di persistenza per l'ambito. Poiché quattro delle forme Send nell'orchestrazione OrderBroker non fanno parte dei gestori di eccezioni e non è necessario eseguire alcuna operazione dopo l'invio, possono entrare in un ambito di transazione atomica. riducendo pertanto il numero di punti di persistenza. Per altre informazioni sulle transazioni atomiche, vedere Transazioni atomiche.
Se tutte le transazioni finiscono nello stesso momento, il motore di orchestrazioni utilizzerà inoltre un singolo punto di persistenza per le transazioni annidate. Pertanto, il modo in cui l'orchestrazione OrderBroker annida ulteriormente le transazioni riduce ulteriormente i punti di persistenza: l'orchestrazione ha un singolo punto di persistenza a causa dell'uso delle forme Scope .
Suggerimento
Per migliorare le prestazioni, è possibile ridurre al minimo il numero di punti di persistenza in un'orchestrazione. È possibile raggruppare le forme Send in una transazione atomica per produrre un singolo punto di persistenza per tutte le forme Send . Se gli ambiti di transazioni annidate finiscono nello stesso momento, si otterrà un singolo punto di persistenza per le transazioni.
Un ambito di transazioni atomiche non può disporre di un gestore di eccezioni. L'orchestrazione annida pertanto l'ambito atomico all'interno di una transazione lunga in esecuzione. Questa transazione esterna può avere un gestore eccezioni ed è questo gestore che elabora un'eccezione dalle forme Send .
Suggerimento
L'annidamento di una transazione atomica all'interno di una transazione lunga in esecuzione è un modello comune per consentire la gestione delle eccezioni.
Vedere anche
Elaborazione nella soluzione di gestione dei processi di business
Logica della gestione processi
Gestione degli interrupt nella soluzione di gestione dei processi di business
Orchestrazione ExceptionHandler