當多個單一訊息必須相互關聯以達成所需結果時，訊息集合便存在。 車隊有兩種主要類型：循序和平行。
在某些情況下，協調流程實例可能會同時接收一組相互關聯的訊息。 在此情況下，可能會發生競爭條件，其中一個群組中的訊息必須在協調流程實例中初始化相互關聯集，其他訊息才能與該協調流程實例相互關聯。
為了確保所有相互關聯的訊息都由相同的協調流程實例接收，BizTalk Server 會偵測這類競爭條件的潛力，並將這些訊息視為車隊。 在註冊時，運行時會建立通用訂閱，並將其辨識為車隊的一部分。 填入此訂用帳戶之後，訊息引擎會根據預先定義的相互關聯屬性中的值來建立暫存訂閱。 此暫時性訂閱稱為 車隊組合。 車隊集合是一組在車隊中使用的相互關聯集。 所有符合一般訂閱的後續訊息都會根據車隊組進行評估，且符合的訊息會被路由到現有的埠。
搭配商業流程使用車隊
搭配商務程式使用車隊處理時，請考慮下列事項：
相互關聯集是屬性清單，其中包含您用來將訊息路由至特定商務程式的特定值。 接收圖形上使用的相互關聯集不能包含用於相互關聯的三個以上屬性。 這是因為這些值會識別並儲存在資料庫層級，最多可支援三個參數。
平行和循序車隊可以共存於相同的商務程式中，但無法彼此共用任何相互關聯集。 這是因為每個相互關聯集只能屬於一個車隊。
當您使用 開始協調流程 圖形將已初始化的關聯集傳遞至新的協調流程時，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），則範例是有效的車隊案例。
殭屍
使用車隊可能會導致「遺失」的訊息，被稱為殭屍。 當執行中協調流程中的非啟動接收訂閱符合 MessageBox 資料庫中的訊息時，MessageBox 會將訊息傳遞至協調流程。 由於 MessageBox 不知道協調流程內的商業規則，因此只會傳遞至協調流程中符合訂用帳戶的所有訊息。 如果協調流程執行時，已超過能夠取用訊息的接收訂閱，則這些訊息中的任何一個都會變成殭屍訊息。
一個會產生殭屍的狀況範例是：在一個迴圈中執行接收操作，迴圈運行 17 次，但有 18 條符合接收訂閱的訊息被傳送。 （MessageBox 不知道協調流程邏輯只會處理 17 則訊息。協調流程不會取用傳遞的第 18 則訊息，因為執行流程已經結束迴圈。 協調流程已經完成，因此無法重啟被捨棄的訊息（殭屍），因為協調流程實例已經完成。
您可以使用 Windows Management Instrumentation （WMI） 腳本來查詢具有「Suspended-NonResumable」狀態的實例，以管理殭屍。 此外，傳訊引擎會將錯誤訊息「已完成且已捨棄的訊息」寫入事件記錄檔。
此外，如果您有具有長時間執行交易範圍的循序車隊，而且該範圍有逾時設定，某些協調流程實例最終可能會處於「暫停-不可恢復」狀態。 您也可以注意到輸出訊息數目加上「已暫止-不可繼續」實例的數目小於輸入訊息的數目。 這行為是經過設計的。 發生逾時例外狀況時，程式代碼會進入例外狀況處理程式。 BizTalk Server 會呼叫例外狀況處理程式，讓它處理例外狀況，包括處理殭屍。 您可以使用例外狀況處理程式中的傳送埠，將殭屍傳送至目的地，以便進一步檢閱和處理。
車隊以外的情況也會生成殭屍。 例如，假設協調流程實例預期來自商務程式的一個回應訊息，而且基於某些原因，它會收到兩個相符的訂用帳戶回應訊息。 在此情況下，第二個回應消息會變成殭屍。 另一個範例是當您有一個接聽圖形，其中一個分支有接收圖形，另一個分支有延遲圖形時。 如果訊息在發生逾時時同時送達，訊息就會變成殭屍。
如需如何管理殭屍的詳細資訊，請參閱 UI 指引和開發人員 API 命名空間參考中的移除暫停的服務實例。