發送轉接器批次管理
在傳送端使用交易時，BizTalk Server 所建立且用於傳送至目標系統的相同交易會在成功傳送後用於對應的訊息刪除。 如果有任何失敗的情況，交易可以結束，在此情況下，刪除會中止，而數據會保留在 BizTalk Server 中，而不是在目標系統中。 這可防止訊息重複。 只有異步傳送配接器才支援交易。 您不應該將交易與同步發送配接器搭配使用。
但是配接器不能只結束交易；它還必須正確地處理交給它的訊息的狀態。 具體來說，適配卡應該根據重試計數以及備份傳輸是否可用，適當地呼叫 Resubmit、 MoveToNextTransport 和 MoveToSuspendQ 方法。
請務必將 Delete 和 SubmitResponse 作業放在使用相同交易的批次中。 失敗的處理方式是結束交易（以確保數據只提交一次至外部系統）。 但您仍想要重新提交或呼叫 MoveToNextTransport ，以取得BizTalk Server上的訊息。 若要這樣做，請針對這些類型的作業使用不同的一般（非交易式）批次。
下圖顯示使用個別批次來傳送回應訊息。
依端點將交易批次 Send-Side 排序
BizTalk Server 傳送至配接器的訊息批次可以跨越多個傳送埠（或端點）。 因為配接器通常想要有單一端點的交易，因此配接器必須根據傳送埠 （SPName 或 OutboundTransportLocation） 排序訊息。 如此一來，配接器就可以建立只跨越特定傳送埠的交易。
例如，當 FTP 傳送配接器從 BizTalk Server 接收一批訊息時，它會取得所有目前使用中 FTP 傳送埠的混合批次訊息。 這是因為 API 是基於單例模式，這表示只會載入單一的 FTP 配接器，而不是每個傳輸埠都載入一個。
配接器必須先將 BizTalk Server 所提供的訊息批次排序為個別批次，每個端點各一個。 然後，它可以接著處理每個端點，而且可能會為每個端點建構刪除批次。 SDK 範例程式代碼中的BaseAdapter泛型可重複使用類別的運作方式相同。
動態傳送的排序
BizTalk Server 協調流程可以將訊息傳送至尚未設定的埠，只要它在訊息標頭和 URL 本身中提供足夠的設定詳細數據。 BizTalk Server 必須辨識 URL 的通訊協定。
排序訊息時，您應該仔細確定什麼構成端點。 在動態傳送的情況下，這特別如此。 如果只有 URI 定義端點，則情況很簡單。 不過，在 FTP 工作階段中，FTP 伺服器可能會使用使用者名稱登入詳細資料來定義真正的端點。 在此情況下，如果配接器以不同的帳戶登入，它可能會連線到不同的目錄。
在某些情況下，除非您執行 Enterprise Single Sign-On （SSO） 命令 ValidateAndRedeemTicket，否則不知道真正的端點。
在 MQSeries 的情況下，判斷是否要使用交易是可設定的。 基於架構和使用遠端 COM+ 物件，應將交易式端點視為與非交易式端點不同。
總結來說，將訊息排序到單一端點的批次有時是不簡單的工作，可能會牽涉到考慮上下文值，甚至可能需要考慮對 SSO 呼叫的結果等額外步驟。
靜態傳送的排序
如果端點是靜態設定的端點，訊息內容上有一個稱為靜態埠標識碼 （SPID） 的唯一 GUID。 這個值可用於排序端點。 下列程式代碼可用來擷取它：
string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");
當您考慮基於 XML 架構定義（XSD）的配置框架所引入的問題時，這會很有幫助。 使用此框架時，您有一個屬性，該屬性可能是埋藏在 XML 中單一上下文屬性內的端點密鑰的一部分。 如果您擁有一個與特定情境相關的SPID，您可以利用它來排序批次。 否則，您會執行動態傳送，而您需要建構用來排序批次的替代索引鍵。
下圖顯示依端點排序的訊息。
請記住，訊息的重試計數無法判定批次的成功或失敗。 在傳送端，一批訊息可能會失敗，因為批次中的少數訊息失敗。 配接器必須判斷它所接收的每個訊息。 在失敗的批次案例中，您可能會假設每個訊息都會重新提交。 不過，如果重新提交失敗批次中的所有訊息，重試計數（由 BizTalk Server 引擎維護）仍會錯誤地增加，即使成功的訊息只是因為與失敗的訊息位於相同的批次中。 在此情況下，配接器可以重新整理傳出的批次，並針對外部系統重新嘗試處理已成功的訊息。