Flusso degli ordini nella gestione processi
In questa sezione viene descritto il modo in cui la gestione dei processi dell'ordine video southridge, l'orchestrazione OrderManager , elabora gli ordini. e viene seguito un nuovo ordine attraverso l'orchestrazione. Viene inoltre illustrato come l'orchestrazione gestisce gli aggiornamenti degli ordini.
Nota
La soluzione di gestione dei processi di business include un solo gestore di processi, nonostante sia stata progettata in modo da poter utilizzare più tipi di gestore.
L'orchestrazione OrderManager coordina le orchestrazioni subordinate che implementano il processo aziendale per gestire l'ordine. OrderManager invia l'ordine attraverso due fasi che, combinate, convalidano l'ordine, inviano le informazioni al gruppo di strutture, inviano l'ordine al sistema di ordine tramite componenti remoti e aggiornano la cronologia degli ordini. È possibile aggiungere, eliminare o modificare queste fasi senza dover modificare OrderManager.
Nota
A causa delle dimensioni e dell'ambito dell'orchestrazione OrderManager , è possibile leggere questa sezione con l'orchestrazione aperta in Microsoft Visual Studio.
Struttura di OrderManager
L'orchestrazione OrderManager inizia con una forma di ricezione che attiva l'orchestrazione. Il diagramma seguente mostra la struttura generale dell'orchestrazione OrderManager .
Dalla prima forma di ricezione si dipartono due rami principali. Quello sulla destra elabora i nuovi ordini. Quello sulla sinistra gestisce gli annullamenti degli ordini. Poiché accetta l'input utente, è possibile che OrderManager riceva un annullamento dell'ordine dopo il completamento di un ordine. Questa è la situazione gestita dal ramo principale sulla sinistra. Questo ramo gestisce un annullamento isolato impostando i flag che consentono di terminare l'elaborazione e aggiungendo un avviso nel registro eventi. L'orchestrazione gestisce gli annullamenti degli ordini che arrivano mentre un ordine è in fase di elaborazione all'interno del ramo sulla destra.
Il ramo di elaborazione degli ordini effettua alcune operazioni di inizializzazione e quindi avvia due cicli nidificati. Il ciclo esterno viene eseguito una volta per ciascuna fase di elaborazione degli ordini. Il ciclo interno viene eseguito durante l'elaborazione della fase. Il gestore degli ordini rimane inoltre in ascolto di possibili aggiornamenti dell'ordine all'interno del ciclo interno. Al termine dei cicli, il gestore degli ordini invia un messaggio di completamento.
Le fasi di elaborazione dell'ordine usano porte dinamiche e auto-correlazioni per comunicare nuovamente all'orchestrazione OrderManager . Ciò semplifica la correlazione di OrderManager con le istanze di fase perché elimina la necessità di usare un set di correlazione. Per altre informazioni sulle porte auto-correlate, vedere Associazioni di porte.
Ricevimento degli ordini
OrderManager riceve i messaggi di ordine dall'orchestrazione OrderBroker tramite la porta FromBrokerPort. Questa porta viene associata direttamente al database MessageBox. L'orchestrazione ha due forme di ricezione connesse alla porta: una per nuovi ordini e una per gli ordini aggiornati.
OrderManger determina quali messaggi elaborare in base a un'espressione di filtro. L'espressione filtro verifica il valore nel campo stato del messaggio e il campo tipo di gestione ordini, OrderMgrType. Se il campo di stato è uguale a ACCETTATO e OrderMgrType è CABLEORDER, l'ordine è nuovo e destinato a questo gestore processi.
Il nuovo ordine attiva una nuova istanza dell'orchestrazione. OrderManager controlla quindi il tipo della richiesta in una forma Decision. Se il tipo è Termina, l'orchestrazione esegue il ramo sulla sinistra e termina l'ordine. In caso contrario, l'orchestrazione procede con l'elaborazione dell'ordine. Questo significa che rimane anche in ascolto dei successivi messaggi correlati all'ordine in questione.
Inizializzazione di nuovi ordini
Dopo che l'orchestrazione OrderManager riceve un messaggio iniziale e inizia il ramo principale a destra, ottiene le informazioni di configurazione da SSOConfigStore. Questa operazione viene eseguita tramite un oggetto singleton definito nell'assembly Utilities . I valori di configurazione sono proprietà dell'oggetto. L'oggetto gestisce una cache locale di valori di configurazione in modo simile alla soluzione Service Oriented Architecture. Per altre informazioni sull'oggetto Singleton, vedere Uso dell'accesso SSO in modo efficiente nella soluzione di gestione dei processi aziendali.
Come la soluzione orientata ai servizi, la soluzione Gestione processo di business utilizza l'archivio segreto perché è presente quando viene installato BizTalk. Inoltre, SSO memorizza nella cache le informazioni di configurazione affinché i valori siano immediatamente disponibili ed è in grado di proteggere informazioni quali stringhe e password per la connessione a database. Per tutti questi motivi, l'archivio segreto è una posizione appropriata per le informazioni di configurazione, anche nel caso in cui non venga utilizzato Single Sign-On per la gestione delle connessioni alle applicazioni back-end.
Nota
L'orchestrazione recupera le informazioni di configurazione prima di avviare l'elaborazione. In questo modo l'orchestrazione utilizza la stessa configurazione nel caso in cui venga disidratata e successivamente reidratata. Per altre informazioni sulla disidratazione, vedere Orchestrazione di disidratazione e reidratazione.
Gestione ordini usa un valore dai dati di configurazione: TotalStages, il numero totale di fasi nel processo di gestione degli ordini. Il gestore assegna questo valore a una variabile locale, numStages. Imposta anche due altre variabili connesse al ciclo esterno, alla fase e all'arresto. La fase indica la fase corrente ed è il contatore per il ciclo esterno; arrestare il valore di arresto.
Infine, il gestore imposta la variabile orderStatus su STARTED e immette il ciclo di elaborazione esterno.
Cicli di elaborazione dei nuovi ordini
Il ciclo esterno viene eseguito fino a quando il valore della variabile di fase è minore del valore della variabile numStages . e gestisce l'elaborazione di ciascuna fase. Il ciclo interno viene eseguito fino a quando viene elaborata una fase. Rimane inoltre in ascolto di possibili modifiche dell'ordine.
Ciclo esterno
L'orchestrazione inizia il ciclo esterno assegnando il messaggio ricevuto (NewOrderMgrMsg) a una variabile, OrderMgrMsg. quindi copia la fase e lo stato nella parte del messaggio relativa al routing. L'orchestrazione imposta anche l'indirizzo restituito nel messaggio sull'indirizzo di StageCompletionPort:
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
L'orchestrazione invia quindi l'ordine a StagePort, una porta di richiesta di risposta. quindi attende dalla fase un riconoscimento dell'avvio dell'elaborazione dell'ordine. La fase invia un messaggio OrderAck all'avvio dell'elaborazione dell'ordine.
Nota
Il messaggio OrderAck è uno dei diversi nella soluzione definita dalle classi .NET anziché da uno schema. Per altre informazioni sull'uso di classi .NET per definire i messaggi, vedere Creazione di messaggi nel codice utente.
Quando l'orchestrazione riceve il riconoscimento, assegna la fase alla variabile currentStage e entra nel ciclo interno.
Ciclo interno
Il ciclo interno viene eseguito fino a quando la variabile currentStage è uguale alla variabile di fase ; ovvero, purché venga elaborata la fase corrente. Il corpo del ciclo è una forma Listen con tre forme di ricezione . La forma più sinistra nell'orchestrazione, Order Request, fa parte del meccanismo di aggiornamento dell'ordine, descritto nella sezione successiva.
Al termine della fase di elaborazione dell'ordine, invia un messaggio alla porta StageCompletion dell'orchestrazioneOrderManager . Se la fase termina bruscamente a causa di un errore, invia un Oggetto TerminateMessage. In questo caso, OrderManager genera un'eccezione. Il gestore di eccezioni più esterno rileva l'eccezione e invia un messaggio di errore al OperatorPort.
Se la fase invia un OrderMgrMsg, OrderManager incrementa la variabile di fase . Se sono presenti più fasi (fase minore o uguale a numStages), le orchestrazioni impostano lo stato dell'ordine in OrderMgrMsg su STAGE_n_COMPLETED dove n è il numero della fase corrente. Se non sono previste altre fasi, lo stato dell'ordine viene impostato su COMPLETED ed entrambi i cicli vengono terminati.
Aggiornamenti degli ordini
L'orchestrazione OrderManager ascolta gli aggiornamenti degli ordini all'interno del ciclo di elaborazione interna. Si noti che la forma Di ricezione usata per questa operazione, OrderRequest, usa anche FromBrokerPort. L'utilizzo di una seconda forma di ricezione sulla stessa porta all'interno di un ciclo costituisce, insieme ai set di correlazioni, un modello comune di BizTalk Server, denominato serie di istruzioni. Il modello della serie di istruzioni serve a garantire che sia il primo messaggio che tutti i successivi messaggi correlati a una particolare operazione vengano elaborati dalla stessa istanza di un'orchestrazione.
Quando il gestore degli ordini riceve il primo messaggio correlato a un ordine, inizializza due set di correlazioni. Il primo, OrderCorrelation, usa l'ID cliente (CustID) e l'ID ordine (OrderID). Il gestore degli ordini condivide questa correlazione con le fasi di elaborazione degli ordini. La seconda correlazione è la correlazione del convoglio, OrderConvoyCorrelation, che usa lo stato dell'ordine (stato) oltre all'ID cliente e all'ID ordine. La forma OrderRequestReceive usa OrderConvoyCorrelation come set di correlazione seguente. Questa impostazione del set di correlazioni serve a garantire che l'istanza del gestore degli ordini assegnata a un particolare ordine riceva tutte le modifiche.
Nota
S ricorda che un set di correlazioni è un raggruppamento di proprietà utilizzate per determinare se un messaggio appartiene a una determinata istanza di un'orchestrazione. Per altre informazioni, vedere Uso delle correlazioni nelle orchestrazioni.
Quando OrderManager riceve un messaggio successivo per un ordine, verifica prima il tipo di richiesta. Se il tipo di richiesta è TERMINATE, la forma Decisione eseguirà il ramo di terminazione. In caso contrario, l'orchestrazione controllerà il nuovo messaggio per verificare se si tratta di un aggiornamento. Un messaggio di aggiornamento ha un numero di sequenza superiore (SeqNum) rispetto alla richiesta originale. Se il numero di sequenza del nuovo messaggio è superiore, l'orchestrazione riavvierà l'elaborazione dell'ordine con il nuovo messaggio. Se il numero di sequenza del messaggio di aggiornamento è pari o inferiore a quello della richiesta originale, si verificherà un errore di sequenza. Se i numeri di sequenza sono uguali, si tratta di un ordine duplicato che viene contrassegnato come un errore di duplicazione.
Per altre informazioni su SeqNum, vedere Messaggi chiave e campi.
Passaggi finali
Dopo aver chiuso i cicli, il gestore ordini assegna l'indirizzo di risposta alla porta dinamica CSRCompletionPort. Il gestore costruisce quindi il messaggio relativo allo stato di completamento, lo invia e verifica l'eventuale presenza di un errore. Se si verifica un errore, l'orchestrazione esegue una forma Termina. In caso contrario, l'orchestrazione ha semplicemente fine.
Coordinamento con le fasi
Sia l'orchestrazione OrderBroker che la seconda orchestrazione della fase di elaborazione (CableOrder2) fanno voci nel database della cronologia. L'orchestrazione CableOrder2 aggiorna le informazioni sulla cronologia immesse dall'orchestrazione OrderBroker . Per assicurarsi che nel database sia presente una voce da aggiornare, OrderBroker usa la notifica di recapito sulla porta usata per il database.
La configurazione esegue il mapping della porta di invio OrderBroker per il database di cronologia a un gruppo di porte di invio contenente due porte, una porta per la configurazione di test (HistoryInsert-Test-SP), una per la configurazione regolare (HistoryInsert-SP). Se si lasciano attive 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. Per altre informazioni sulla notifica di recapito, vedere Uso dei riconoscimenti.
Scelte a livello di progettazione per gli errori e il routing dei messaggi corretti
L'orchestrazione e le orchestrazioni del gestore eccezioni usate dalle fasi di elaborazione dell'ordine usano un'orchestrazione di gestione degli errori (ErrorHandlerOrch) per instradare ordini non valida per la riparazione. Nella progettazione si suppone che vi sia un reparto o un gruppo in grado di correggere l'ordine nella maniera necessaria. L'ordine riparato non viene restituito tramite l'orchestrazione di order broker (OrderBroker). L'ordine normalizzato viene invece corretto nella forma normalizzata. In base alla progettazione corrente della soluzione, l'orchestrazione del gestore esegue il routing del messaggio di errore verso l'origine dell'ordine originale. È tuttavia necessario eseguire il routing degli ordini corretti a una porta MSMQ nell'orchestrazione del gestore degli errori. La versione di test della soluzione usa una cartella file. Il gestore degli errori restituisce quindi il messaggio ripristinato all'orchestrazione chiamante.
In questa soluzione viene utilizzata la progettazione illustrata perché il broker degli ordini esegue una considerevole quantità di convalide e normalizzazioni del messaggio relativo all'ordine. Il messaggio relativo all'ordine da correggere è a sua volta nella forma normalizzata. L'utilizzo della forma normalizzata del messaggio consente di non tener conto della differenza tra le forme inviata e normalizzata dei messaggi.