2013-09-27 101 views
0

在我的場景中,我有一個管道(1)解密,然後(2)在接收端口上拆卸平面文件。BizTalk歸檔管道組件考慮

我的要求是捕獲文件,並將其放在(1)和(2)之間的本地文件共享中。

我最初的做法是在它們之間引入一個Archive組件,但是我遇到了這個問題。存檔組件使用對存儲的直接訪問來轉儲文件。根據BizTalk原則,這實質上是很差的方法,這是發送端口/發送適配器的功能。因此,如果存檔目標是FTP主機,則存檔組件無用。

因此兩個想法浮現在腦海中:

A)不知何故配置歸檔組件使用發送端口(如果這甚至有可能)

B)放棄歸檔組件的想法,只是使用BizTalk的本機的功能如下:

- 接收使用僅解密管道

- 發送使用發送端口

文件到臨時本地存儲的文件210

-Subscribe到接收端口將文件發送到歸檔

-pick起來使用拆卸管道文件形式本地存儲器(第二接收端口)

- 使用業務流程處理來自所述第二文件接收端口。

選項B)有沒有問題?

如果不是,那麼即使使用歸檔組件也有什麼意義?

回答

1

其他選項還包括

C)有一個檔案發送端口和一個回送發送端口訂閱接收端口的環回發送端口會對接收平面文件僞君子。

D)有一個存檔發送端口和訂閱接收端口的編排。調用Orchestration中的拆分管道。

我們已經將這兩種情景用於不同的解決方案。

+0

不錯的選擇。這是一個關於如何做的例子D) http://www.codeproject.com/Tips/603145/Calling-ReceivePipeline-from-Orchestration-to-perf – LastTribunal

1

如果您正在使用Native Biztalk功能設置發送端口訂閱消息類型的存檔是足夠的。

如果您使用的是BizTalk ESB工具包由於您在管道上下文中執行,因此很難分割郵件進行歸檔。在您的行程中使用編排將允許您拆分消息,但當然需要行程離開管道並將消息放在消息框中。只是做簡單的消息歸檔可能會使這個解決方案被過度殺死。

您可以使用自定義管道組件,如下面的組件。它是一個可重用的管道組件,可用於BizTalk ESB工具箱場景(如果您想要將原始消息轉換爲原始消息,那麼該場景非常方便),作爲文件歸檔或SQL歸檔,並可在入站和出站流水線場景中使用。

BizTalk Archiving - SQL and File

您將只負責維護舊的/不需要的郵件,以避免膨脹。