我不知道如果我問正確的問題，但是這是我試圖運行的方案：的BizTalk自定義適配器
多個文件（XML和一些相關文件，「附件」）必須進入BizTalk作爲單個消息。我查看了現有的適配器，並沒有看到現有的一次完成。爲了更加準確，文件從文件系統中獲取。文件不能同時找到，但是不能保證訂單時一次到達一個文件。 XML（內容）文件是知道它必須具有哪些附件（其他文件是什麼）的文件。
我們正在研究BizTalk 2009，我想知道是自定義適配器或其他的責任。我可以找樣品嗎？
謝謝。
這可能是可以做到你想使用自定義適配器，但我建議不要這樣做。您可以使用編排來實現您的要求。
你在找什麼就像一個車隊，或者至少有一些使用的相關性。
在BizTalk中，車隊是一種消息傳遞模式（與BizTalk功能相反），它允許單個業務流程處理消息組。
實際上，您使用接收端口上的相關性將消息按並行（您可能需要）或順序方式分組在一起。
Stephen W. Thomas的文章[here]（http://msdn.microsoft.com/en-us/library/ms942189(BTS.10).aspx)）關於車隊（這是爲BT 2004，但概念仍然存在），並且網上和書籍上有很多附加信息（專業BizTalk服務器2006年對他們有一個小節）
沒有關於你的情況的更多細節，很難確切知道如何建立車隊，但下面是兩種方法來看待（也沒有機會正確使用BT2009所以可能會延長對相關場景的支持，幫助您解決問題）
靈活的相關性
如果您不瞭解上下文XML中列出的文件的任何內容，您可能需要一個類似於Charles Young在this後所描述的模式。
非均勻連續的護航
如果你有前手信息的一點點一種方法可能如下（基本上是一個非均勻連續的車隊）：
這使得假設有一些方法可以將所有文件鏈接在一起，以便將它們關聯起來。
創建訂閱您的入站接收端口（包含文件接收位置）的單個業務流程。
此業務流程將爲您的內容文件設置單個激活接收形狀。
一旦內容文件啓動編排，第二個相關的接收形狀開始拾取與該內容文件相匹配的消息。（第二次接收可能在一個循環中以允許可變數量的文件）
然後，您將它們全部打包到設計的單個出站文件中，並在收到完整數量的文件後將其發送出去。
對我來說似乎更好的方法是使用自定義管道組件和/或自定義適配器來實現上述要求。我假設你並不需要操縱傳入的文件 - 除了內容XML文件 - 或者你無法操作，因爲它們是二進制格式。這需要一個自定義管道組件。
你可以做的是開發一個定製的BizTalk適配器來與文件系統交互並實現監聽和循環邏輯。接下來，您可以開發一個自定義管道組件來創建一個單一的BizTalk消息，其中可能包含base64數據類型以用於二進制數據。此外，您還可以在此組件中促進消息，以啓用業務流程訂閱。
編排更適合於實現業務工作流場景，其中消息已經是XML格式。這似乎並非如此。無論如何，我認爲至少需要一個自定義管道組件。
謝謝。這聽起來像我們將不得不做的。我們將需要對涉及編排/外部服務的消息/附件進行操作。 – 2009-11-17 20:05:26
大衛的回答是正確的答案。
即使您對預期附件的內容完全不瞭解，也一定知道它們的名稱和位置。因此，您可以使用靈活關聯鏈接到這樣的大衛的回答：
解決方案的關鍵是關聯內置BTS.ReceivedFileName屬性。
首先，創建一個自定義接收管道，使用自定義管道組件來提升接收到的消息的BTS.ReceivedFileName上下文屬性。這個簡單的自定義組件相當容易編寫，但您可以通過使用第三方框架，如（無恥插件，這裏是），我的PipelineComponentBase類或優秀的BizTalk Server Pipeline Component Wizard使它變得簡單。
現在對於比較容易的部分：
請注意，您實際上需要發送消息以初始化關聯。實際發送的信息無關緊要。我要做的就是通過發送管道發送消息，該管道包含一個空的管道組件。這是一個讀取消息但返回null的管道組件（以便消息在到達適配器之前消失）。更復雜的解決方案是使用適配器。這是一個讀取消息的適配器，但對此不做任何處理。
這兩個解決方案避免了許多文件在某處的臨時位置積累，只是爲了初始化相關性！
David， 感謝您提供此信息。護衛隊看起來很有趣，但我不確定在這種情況下它將如何工作。你看，附件是二進制文件，並且對內容XML文件一無所知。這些附件沒有任何促進。也許我錯過了一些東西，隨時指出這一點。 10x 肖恩 – 2009-11-09 14:52:05
這顯然是正確的答案。即使你對XML文件的內容一無所知，你一定知道它的名字和位置。從這裏，你可以使用靈活的相關性如下： – 2010-12-18 21:15:53