當交易整合器（TI）元件在交易中執行時，TI 執行環境會向 COM+ 環境中的 Microsoft 分散式交易協調器（DTC）發送訊息，並以特殊類型的 LU 6.2 資源管理器身份登錄於該交易中。 TI 將資料緩衝區傳送給主機並收到回覆後，會呼叫該 SetComplete 方法並將控制權回還給 COM+。 此時，客戶端應用程式或其他驅動 TI 的元件，也能執行同一交易中包含的其他工作。 當所有資源管理器完成更新併發出SetComplete後，創建交易的對象（可以是自動交易的 COM+ 本身）會將Commit方法發送給 DTC。 DTC 會將第一階段（Prepare）訊息傳送給所有資源管理器，包括 TI 執行時環境。 TI 會產生 SNA 格式中定義的資訊 Prepare PS Header ，並將其傳送給主機。 它會收到回覆 RequestCommit ，表示主機更新有效且可提交，並將此資訊回傳給 DTC。 DTC 會收集所有資源管理器的投票，如果準備都正常，會強制寫入一個提交記錄到日誌並發送 Committed 訊息。 同樣地，TI 會將此轉換成 SNA PS Header，接收回覆，再轉回 DTC。 如果一切順利，DTC 會回復該交易，APPC/LU 6.2 的對話也會被釋放。
備註
TI 和 AP 都不需要擔心 APPC 或 CPI/C 的 SYNCPT 命令。 「取得 SyncPoint 」的決定由交易創建者做出，並以 OLE 交易的語意表達，且涉及所有交易參與者，而非僅限於 TI LU 6.2 分支。 TI 的角色較低;TI 作為 DTC 的資源管理器。 它在 DTC 使用的 COM 介面與主機所理解的 SNA 協定間轉換，執行協定的兩個階段，並使 DTC 能在第一階段與第二階段之間做出提交決策。
從效能角度來看，確保主機更新的原子性會增加大量且無法避免的開銷。 對於兩階段提交（2PC），還有兩個額外的往返訊息流至主機，另外，還包括 Windows 訊息流的註冊，以及 DTC 和主機上的交易記錄（強制磁碟寫入）。 不需要大量商業邏輯處理的交易，與沒有 2PC 的同一交易相比，完成時間可能是兩倍甚至更長。
唯一應該配置 TI 元件以支援 ACID 交易的情況，是當相關的主機交易程式（TP）修改了必須與 Windows 作業系統資源保持一致的關鍵任務資源時。 若 TP 不願修改任何必須保證一致性的資源，則將 TI 元件配置為 「不支援交易」，以避免嘗試 2PC。 這樣你也可以自由使用 TCP/IP 協定。 TCP/IP 協定不支援 2PC。
TI 元件絕不應該被設定為 需要新交易。 這表示你是遠端為主機管理交易，會產生建立新交易、註冊和與主機進行雙PC交換的額外負擔，但 TI 方法本身就是一個交易。 讓 CICS 和 IMS 自行管理交易會更有效率。 Windows 作業系統的任何更新都不屬於該交易的一部分，因此這些更新會獨立地提交或回滾。
備註
在同一台伺服器上進行額外的商業邏輯處理會降低吞吐量限制，並消耗部分 CPU。 然而，在整體回應時間預算中，成本可能相對較小。