透過處理序管理員的訂單流程
本節說明 Southridge Video 訂購程式管理員 OrderManager 協調流程、處理訂單的方式。 本節會透過協調流程來產生新訂單。 本節也討論協調流程如何處理訂單的更新。
注意
商務程序管理員解決方案只包含一個程序管理員，即使該程序管理員是已寫入的，這樣它才能使用一種以上的管理員。
OrderManager協調流程協調次級協調流程，以實作商務程式來處理訂單。 OrderManager會透過合併、驗證訂單、將資訊傳送至設施群組、透過遠端元件將訂單傳送至訂單系統，以及更新訂單歷程記錄的兩個階段來傳送訂單。 您可以新增、刪除或修改這些階段，而不需要變更 OrderManager。
注意
由於 OrderManager 協調流程的大小和範圍，您可能會想要閱讀本節，並在 Microsoft Visual Studio 中開啟協調流程。
訂單管理員結構
OrderManager協調流程從啟動協調流程的接收圖形開始。 下圖顯示 OrderManager 協調流程的一般結構。
第一個接收圖形會分成兩個主要分支。 右邊的分支會處理新的訂單。 左邊的分支會處理訂單取消作業。 因為它接受使用者輸入， 所以 OrderManager 可以在訂單完成之後收到訂單取消。 這就是左邊主要分支處理的狀況。 分支藉由設定終止處理的旗標並將警告新增到事件日誌，來處理外掛式取消作業。 當右邊的分支內正在處理訂單時，協調流程會處理抵達的訂單取消作業。
訂單處理分支會進行部分初始化，然後進入兩個巢狀迴圈。 在訂單處理過程中，每個階段都會執行一次外部迴圈。 當階段正在處理時會執行內部迴圈。 訂單管理員也會接聽內部迴圈中訂單的可能更新。 在迴圈終止後，訂單管理員會傳送一個完成訊息。
訂單處理階段會使用動態、自我關聯埠來與 OrderManager 協調流程通訊。 這可簡化 OrderManager 與階段實例的相互關聯，因為它不需要使用相互關聯集。 如需自我關聯埠的詳細資訊，請參閱 埠系結。
接收訂單
OrderManager會透過FromBrokerPort埠從OrderBroker協調流程接收訂單訊息。 這個連接埠直接繫結至 MessageBox 資料庫。 協調流程有兩個連線到埠的 接收 圖形：一個用於新訂單，另一個用於更新的訂單。
OrderManger會根據篩選運算式決定要處理的訊息。 篩選運算式會測試 [訊息狀態] 欄位和 [訂單管理員類型] 欄位 OrderMgrType中的值。 如果狀態欄位等於 ACCEPTED，而 OrderMgrType 為 CABLEORDER，則訂單是新的，而且適用于此進程管理員。
新訂單會啟動協調流程的一個新執行個體。 OrderManager接著會檢查Decision圖形中的要求類型。 如果類型是「終止」，協調流程會執行左邊的分支並終止訂單。 否則，協調流程會繼續處理訂單。 請注意，這包含接聽與此特定訂單相關的後續訊息。
新訂單的初始化
在 OrderManager協調流程收到初始訊息並開始主要右側分支之後，它會從SSOConfigStore取得其設定資訊。 它會透過 公用程式 元件中定義的單一物件執行此動作。 組態值是物件的屬性。 物件會管理組態值的本機快取，與服務導向架構解決方案相似。 如需單一物件的詳細資訊，請參閱 在商務程式管理解決方案中有效率地使用 SSO。
如同服務導向解決方案，商務程序管理解決方案會使用密碼存放區，因為它在安裝了 BizTalk 就會出現，SSO 會快取組態資訊，如此一來這些值便能使用，並可保護資料庫連接字串和密碼這類的資訊。 基於上述所有原因，密碼存放區是非常適合放置組態資訊的位置，即使單一登入不是用於管理與後端應用程式的連線。
注意
協調流程會在開始處理之前，先擷取組態資訊。 這可確保協調流程在凍結及稍後解除凍結時會使用相同的組態。 如需解除凍結的詳細資訊，請參閱 協調流程解除凍結和解除凍結。
訂單管理員會使用組態資料的一個值： TotalStages、訂單處理常式中的階段總數。 管理員會將此值指派給區域變數 numStages。 它也會設定兩個連線到外部迴圈、 暫存 和 停止的變數。 階段表示目前階段，而且是外部迴圈的計數器;停止停止值。
最後，管理員會將 orderStatus 變數設定為 STARTED，並進入外部處理迴圈。
新的訂單處理迴圈
只要 階段 變數的值小於 numStages 變數的值，外部迴圈就會執行。 外部迴圈會驅動每個階段的處理。 只要階段仍在處理中，內部迴圈就會執行。 它也會接聽訂單的可能變更。
外部迴圈
協調流程會藉由將接收的訊息 (NewOrderMgrMsg) 指派給 變數 OrderMgrMsg，以開始外部迴圈。 接著它會將階段和狀態複製到訊息的路由部分。 協調流程也會將訊息中的傳回位址設定為 StageCompletionPort的位址：
OrderMgrMsg.RoutingPart.OrderMgrReturnAddress =
StageCompletionPort(Microsoft.XLANGs.BaseTypes.Address);
協調流程接著會將訂單傳送至 StagePort，這是請求回應埠。 然後協調流程會等候來自已開始訂單處理之階段的通知。 階段會在開始處理訂單時傳送 OrderAck 訊息。
注意
OrderAck訊息是 .NET 類別所定義之解決方案中的數個訊息之一，而不是架構。 如需使用 .NET 類別定義訊息的詳細資訊，請參閱 在使用者程式碼中建構訊息。
當協調流程收到通知時，它會將階段指派給 currentStage 變數，並進入內部迴圈。
內部迴圈
只要 currentStage 變數等於 階段 變數，內部迴圈就會執行;也就是說，只要正在處理目前的階段。 迴圈的主體是具有三個接收圖形的接聽圖形。 協調流程最左邊的圖形 Order Request是訂單更新機制的一部分，如下一節所述。
當訂單處理階段完成時，它會將訊息傳送至OrderManager協調流程的StageCompletion埠。 如果階段因錯誤而突然終止，則會傳送 TerminatedMessage。 在此情況下， OrderManager 會擲回例外狀況。 最外層的例外狀況處理常式會攔截例外狀況，並將錯誤訊息傳送至 OperatorPort。
如果階段傳送OrderMgrMsg，OrderManager會遞增階段變數。 如果階段 (階段小於或等於 numStages) ，協調流程會將 OrderMgrMsg 中的順序狀態設定為 STAGE_n_COMPLETED其中 n 是目前階段的數目。 如果沒有更多的階段，它會將訂單狀態設為 COMPLETED 並結束這兩個迴圈。
訂單更新
OrderManager協調流程會接聽內部處理迴圈內的訂單更新。 請注意，它用於此OrderRequest的Receive圖形也會使用FromBrokerPort。 在迴圈內部的相同連接埠上使用第二個接收圖形，來結合相互關聯集，會形成通用 BizTalk Server 模式，也就是群組模式。 您可以使用群組模式，來確保協調流程的相同執行個體會處理第一個及後續與特定作業連接的訊息。
當訂單管理員接收到第一個與訂單連接的訊息時，它會初始化兩個相互關聯集。 第一個 OrderCorrelation會使用客戶識別碼 (CustID) 和訂單識別碼 (OrderID) 。 訂單管理員會與訂單處理階段共用這個相互關聯。 第二個相互關聯是Convoy 相互關聯 OrderConvoyCorrelation，除了客戶識別碼和訂單識別碼之外，還會使用訂單狀態 (狀態) 。 OrderRequestReceive圖形使用OrderConvoyCorrelation做為下列相互關聯集。 使用這個方式來設定相互關聯集，可以確保負責特定訂單的訂單管理員執行個體能夠接收到任何的變更。
注意
請記住，相互關聯集是一個訊息屬性的群組，可用於判斷訊息是否屬於協調流程的特定執行個體。 如需詳細資訊，請參閱 在協調流程中使用相互關聯。
當 OrderManager 收到訂單的後續訊息時，它會先測試要求的類型。 若要求類型是 TERMINATE，「決策」圖形就會執行終止分支。 否則，協調流程會測試新的訊息，以查看它是否為更新。 更新訊息的序號 (SeqNum) 高於原始要求。 若新訊息的序號更高，協調流程會以新訊息重新啟動訂單處理。 若原始和更新訊息具有相同或更低的序號，就會發生順序錯誤。 若序號相等，則其為重複的訂單，並標示為重複的錯誤。
如需 SeqNum的詳細資訊，請參閱 索引鍵訊息和欄位。
最後步驟
結束迴圈之後，訂單管理員會將回復位址指派給動態埠 CSRCompletionPort。 接著管理員會建構完成狀態訊息、傳送它，然後測試是否有錯誤。 若有錯誤，協調流程會執行「終止」圖形，否則它就會停止。
與階段進行協調
OrderBroker協調流程和第二個處理階段協調流程 (CableOrder2) 在歷程記錄資料庫中建立專案。 CableOrder2 協調流程會更新 OrderBroker 協調流程所輸入的歷程記錄資訊。 為了確保資料庫中有要更新的專案， OrderBroker 會在用於資料庫的埠上使用傳遞通知。
組態會將歷程記錄資料庫的 OrderBroker 傳送埠對應至包含兩個埠的傳送埠群組：一個埠用於測試組態 (HistoryInsert-Test-SP) ，一個用於一般設定 (HistoryInsert-SP) 。 若您讓群組中的兩個連接埠皆為作用中，那麼解決方案會在這兩個連接埠上傳送訊息。 因此它會要求兩個傳遞通知，但只會處理其中一個。
若要避免這種情況，請將測試埠取消列出 (HistoryInsert-Test-SP) ，或停止應用程式的測試版本。 如需傳遞通知的詳細資訊，請參閱 使用通知。
錯誤與路由修復訊息—設計選擇
訂單處理階段所使用的例外狀況處理常式協調流程和協調流程會使用錯誤處理協調流程 (ErrorHandlerOrch) 來路由修復錯誤的訂單。 此設計會假設有一個部門或群組將需要在表單中修復訂單。 已修復的訂單不會透過訂單代理程式協調流程重新提交， (OrderBroker) 。 當然，標準化訂單會在其標準化表單中修復。 解決方案的目前設計會讓處理常式協調流程將錯誤訊息路由回到原始訂單的來源。 不過，修復的訂單必須路由到錯誤處理常式協調流程上的 MSMQ 連接埠。 (解決方案的測試版本會使用 file folder.) 錯誤處理常式，然後將修復的訊息傳回至呼叫協調流程。
這個解決方案使用這個設計，是因為訂單仲介會對訂單訊息進行重要的驗證和標準化。 接著，要求修復的訂單訊息也會在標準化表單中。 維護訊息的標準化表單，可避免必須處理訊息之已提交表單與標準化表單之間的差異性。