BizTalk Server 能夠從協調流程內同步呼叫管線。 這可讓協作程序利用管線內封裝的訊息處理（傳送或接收）對數據內容進行處理，而不需要透過傳訊基礎結構傳送該數據。
您可以使用這項功能讓協調流程呼叫傳送管線，以便將數個訊息匯總成單一傳出交換。 相反地，編排可以呼叫接收管線來解碼和拆解在訊息傳遞架構外部取得的交換集，而不會產生通過訊息匣的處理成本。
詳細資訊
協調流程會使用 XLANGPipelineManager 類別中的方法（在 Microsoft.XLANGs.Pipeline 命名空間中）呼叫傳送或接收管線。 接收管線會取用單一訊息或交換格式，並產生零或多個訊息，就像管線在 BizTalk 訊息系統中接收訊息內容時執行一樣。 傳送管道會處理一或多個訊息，並產生單一訊息或訊息交換，這就像管道在 BizTalk 訊息傳送環境中執行時的情形。
呼叫接收管線
為了從協調流程內呼叫接收管線，應用程式會呼叫 XLANGPipelineManager 類別的 ExecuteReceivePipeline（） 方法。 此方法會取用單一交換，並傳回零個或多個訊息的集合（包含在 ReceivePipelineOutputMessages 類別的實例中）。 這個方法的語法詳述於 XLANGPipelineManager 類別的 .NET 類別庫參考中。
從協調流程內執行接收管線的 API 為：
// Execute receive pipeline
static public ReceivePipelineOutputMessages ExecuteReceivePipeline(System.Type receivePipelineType, XLANGMessage msg);
對接收管線的呼叫通常會在協調流程內的 表達式 圖形中完成。
若要從協調流程內呼叫接收管線，開發人員必須參考協調流程專案中的管線元件。 以下是呼叫接收管線之協調流程的範例：
如需更詳細的範例，請參閱 SDK 範例撰寫訊息處理器（BizTalk Server 範例）。
備註
ReceivePipelineOutputMessages 類型的變數只能在協奏流程的原子範疇內宣告。 這是因為此類型的變數無法序列化，因此不會在協調流程的持久化中存留，而且協調流程在原子範疇範圍內執行時永遠不會被保存。 這表示接收管線只能在原子範圍內執行。
備註
從協調流程內呼叫 PassThruReceive 管線或自定義管線元件時，您必須將傳入訊息的變數類型宣告為 System.Xml.XmlDocument，儘管傳入訊息類型為 XML 或不是 XML。 因此，當您嘗試執行操作於傳入訊息是非 XML 訊息時，例如一般文件格式訊息，您可能會遇到例外狀況。 這是因為該協調流程引擎打算針對上述案例中的任何類型的傳入訊息使用System.Xml.XmlDocument。
呼叫發送管道
若要從協調流程內呼叫傳送管線，應用程式會呼叫 XLANGPipelineManager 類別的 ExecuteSendPipeline（） 方法。 這個方法會取用一或多個訊息的集合（包含在 SendPipelineInputMessages 類別的實例中），並傳回單一交換。 這個方法的語法詳述於 XLANGPipelineManager 類別的 .NET 類別庫參考中。 由於執行傳送管線會產生新的交換，因此必須在訊息指派圖形內呼叫 ExecuteSendPipeline（） 方法，例如：
從協調流程內執行傳送管線的 API 為：
// Execute a send pipeline
static public ExecuteSendPipeline(System.Type sendPipelineType, SendPipelineInputMessages inputMsgs, XLANGMessage msg);
對傳送管線的呼叫必須在協調流程內的 訊息指派 圖形中完成。
若要從協調流程內呼叫傳送管線，開發人員必須參考協調流程專案中的管線元件。 呼叫傳送管線的協調流程範例：
備註
呼叫預設的 XMLTransmit 管線時，您必須將訊息上下文屬性 XMLNORM.EnvelopeSpecName 設定為 Envelope 架構的完整限定名稱。 例如：
MyMessage(XMLNORM.EnvelopeSpecName) = "PipelineSchemas.POEnv, PipelineSchemas, Version=1.0.0.0, Culture=nuetral, PublicKeyToken=12e5cc95621c33e8";
如需更詳細的範例，請參閱 SDK 範例匯總工具（BizTalk Server 範例）。
管線執行 - 行為上的差異
協調處理序呼叫執行傳送或接收管線時的行為大致上與管線在傳訊基礎結構中執行的情況（例如在接收位置或傳送埠）相同。 不過，下面有一些行為差異。
管線階段內的差異
從 BizTalk 編排流程內部呼叫的傳送或接收管道中各階段的執行，與從 BizTalk 傳訊基礎設施呼叫管道執行這些階段幾乎完全一致，除了以下各階段的例外狀況。
組合器/反彙編工具：組合器和反彙編工具不會處理 追蹤設定檔案 數據。
編碼器/譯碼器：MIME 編碼器會使用主機相關聯主機所設定的憑證，以數位方式簽署訊息。 SMIME 編碼器會使用傳遞至管線之訊息內容上的憑證來加密訊息。
架構解析
從協調流程執行管線時，支援兩種架構查閱演算法：
按類型解析
依名稱解析
在部署重複架構的情況下，選取適當架構的演算法邏輯與在傳訊基礎結構內容中執行時所使用的相同。
交易式管線
階段呼叫交易式元件的管線不會有可用的交易內容。 任何對 IPipelineContext.GetTransaction（） 的呼叫都會擲回 NotSupportedException。 這並不排除從協調流程執行這類管線，但表示管線必須偵測及處理這種情況。
訊息目的地
在此內容中不支援透過管線元件控制訊息目的地。 設定內容屬性 MessageDestination 或 SuspendOnRoutingFailure 會導致擲回 XLANGPipelineManagerException 。
管線元件類型
管道元件必須建立於以下標準，才能從編排內呼叫：
.NET Framework v1.1
.NET Framework v2.0
.NET Framework v3.0
.NET Framework v3.5
.NET Framework v4.0
.NET Framework v2.0
COM
限制
下列類型的管線 無法 從協調流程內執行：
交易流程
可復原的管線
若呼叫 BAM 攔截器 API 的管線，將會擲回 NotSupportedException。
除非相同的管線實例位於每個分支的同步處理範圍中，否則無法在平行圖形的不同分支中執行。
針對 BizTalk Server 2006 SDK 建置的現有管線（元件）。
失敗模式和效果
管線執行中導致暫停訊息的任何失敗，都是從 BizTalk Server 傳訊基礎結構內呼叫此管線，反而會導致擲回例外狀況。 擲回的例外狀況的類型 為 Microsoft.XLANGs.Pipeline.XLANGPipelineManagerException。 這個擲回的例外狀況可以在呼叫協調流程內的 catch 區塊中處理。 如果協調流程未攔截擲出的例外狀況，XLANGs 引擎會報告錯誤，錯誤文本中包含擲出的例外狀況的詳細資訊。
例外狀況會執行管線元件所產生的錯誤訊息格式設定。
XLANGPipelineManagerException 類別的 Message 屬性包含管線執行錯誤的詳細數據。 此詳細資料的格式如下：
執行管線 <類型>時發生失敗。 錯誤詳細資訊 <格式化的錯誤訊息>。
在此訊息中， <管線類型> 是管線類別的名稱，而 <格式化的錯誤訊息> 是管線執行期間發生之特定失敗的描述。
例如，如果協調流程呼叫接收管線，且該管線的執行失敗，因為管線的元件都無法辨識訊息， XLANGPipelineManagerException 的屬性值會是：
| XLANGPipelineManagerException 属性 | 價值觀 |
|---|---|
| 訊息 | 執行接收管線 「MyPipelines.ReceivePipeline」 失敗。 錯誤詳細數據：「沒有可反組譯階段元件可以辨識數據。 |
| 元件 | String.Empty |
另一個範例是，如果協調流程呼叫傳送管線，且該管線的執行因為驗證失敗而失敗，XLANGPipelineManagerException 的 Message 屬性中的文字會是：
| XLANGPipelineManagerException 属性 | 價值觀 |
|---|---|
| 訊息 | 執行傳送管線 「MyPipelines.SendPipeline」 時發生失敗。 錯誤詳情：「無法驗證該文件：「元素名稱< 無效 - 值 <元素值> 根據其數據類型 '字串' 無效 - 模式約束失敗」。 |
| 元件 | “Microsoft.BizTalk.Component.XmlValidator” |