使用群組實例
每當有多個單一訊息必須與達成必要結果相關時， 就存在一個佇列 。 Convoy 有兩種主要類型：循序和平行。
在特定情況下，協調流程執行個體會同時接收一組相互關聯的訊息。 此時，便可能發生競爭情形，因此群組的其中一個訊息必須初始化協調流程執行個體中的相互關聯集，才能讓其他訊息與該協調流程執行個體相互關聯。
為確保所有的相互關聯訊息都是由相同的協調流程執行個體所接收，BizTalk Server 會偵測這種可能存在的競爭情形，並將這些訊息視為一個群組。 在登錄過程中，執行階段會建立一般訂閱，並將其認定為群組的一部分。 填寫該訂閱後，傳訊引擎便根據預先定義的相互關聯屬性值建立暫時訂閱。 此暫存訂用帳戶稱為 convoy 集合。 群組集是在群組中使用的一組相互關聯集。 所有符合一般訂閱的後續訊息都是對照群組集評估而得，那些符合的訊息會路由傳送至現有的連接埠。
搭配商務程序使用群組
搭配商務程序使用群組處理時，請考慮下列事項：
相互關聯集是屬性清單，其中包含您用來將訊息路由傳送至特定商務程式的特定值。 接收圖形上使用的相互關聯集不能包含三個以上的屬性，用於相互關聯。 原因是這些值是在資料庫層級上識別和儲存的，而此層級最多只支援三個參數。
平行和循序群組可以並存於相同的商務程序，但無法彼此共用任何相互關聯集。 這是因為每一個相互關聯集只能屬於一個群組。
當您使用[開始協調流程] 圖形將已初始化的相互關聯集傳遞至新的協調流程時，BizTalk Server不支援串流處理。 這是因為群組集已在資料庫層級經過處理，與已經在執行中的協調流程執行個體無關。
您無法使用單一 接收 圖形來初始化兩個或多個將在個別串送中使用的相互關聯集。 例如，假設「接收 r1」初始化第一個群組的相互關聯集 c1 和 c2，「接收 r2」沿用 c1 後成為第二個群組，然後「接收 r3」沿用 c2 後成為第三個群組。 第二個群組的預定群組集是 c1、r2，而第三個群組的預定群組集是 c2、r3，都是由 r1 初始化的。 在這種情況下，協調流程引擎不會將這些訊息視為群組。 如果 r2 和 r3 兩者，都沿用 c1 和 c2 (c1、r2、r3 和 c2、r2、r3)；都只沿用 c1 (c1、r2、r3)；或者都只沿用 c2 (c2、r2、r3)，則此範例即為有效的群組實例。
Zombie
使用群組可能產生所謂 Zombie 的「遺失」訊息。 當執行中協調流程內之非啟動中的接收訂閱符合 MessageBox 資料庫中的訊息時，MessageBox 便會將該訊息傳送到協調流程。 因為 MessageBox 並不瞭解協調流程內部的商務邏輯，它只是一律將所有符合訂閱範圍的訊息傳送給協調流程。 如果這些訊息中有任何訊息錯過協調流程執行流程中、可以取用訊息的接收訂閱期間，那麼這個訊息就會成為 Zombie。
這裡試舉一個產生 Zombie 的狀況當做範例：在反覆 17 次的迴圈內有一個接收，但在迴圈反覆期間傳送了 18 個符合接收訂閱的訊息 (MessageBox 不知道協調流程邏輯只會處理 17 則訊息。) 協調流程所傳遞的第 18 則訊息不會由協調流程取用，因為執行流程已經結束迴圈。 協調流程已完成，但有捨棄的訊息 (Zombie)，而這些訊息是不可繼續處理的，因為協調流程執行個體已經完成。
您可以管理 Zombie，方法是使用 Windows Management Instrumentation (WMI) 指令碼，查詢狀態為「擱置 (不可繼續)」的執行個體。 傳訊引擎也會另外將錯誤訊息「完成並有捨棄的訊息」寫入事件日誌。
此外，如果您的循序群組中有長時間執行的交易式範圍，而該範圍還有逾時設定，則某些協調流程執行個體可能會以「擱置 (不可繼續)」狀態結束。 您可能也會發現，輸出訊息數加上「擱置 (不可繼續)」執行個體數，小於輸入訊息數。 此行為是設計所致。 當逾時例外狀況發生時，程式碼執行流程會進入例外狀況處理常式。 BizTalk Server 會呼叫例外狀況處理常式，交由它來處理例外狀況，包括處理 Zombie。 您可以在例外狀況處理常式中使用傳送埠，將 Zombie 傳送至某個目的地，進一步加以檢視和處理。
群組以外的實例也可能產生 Zombie。 例如，假設協調流程執行個體預期商務程序會送來一個回應訊息，但不知何故，卻收到兩個符合訂閱的回應訊息。 在這種情況下，第二個回應訊息便會成為 Zombie。 另一個範例是當您有一個分支有接收圖形的接聽圖形，而另一個分支有延遲圖形時。 如果訊息在逾時狀況發生當時抵達，則此訊息會變成 Zombie。
如需如何管理分解的詳細資訊，請參閱UI 指引和開發人員 API 命名空間參考中的移除暫停的服務實例。