MessageBox直接綁定端口上的相關性

Question

我有一個業務流程，名爲MyUsefulOrch，託管在應用程序MySharedApp中。

MyUsefulOrch有一個入站messagebox-direct-bound端口來接收請求，並且在做了一些有用的工作之後，出站messagebox-direct-bound端口發送消息給調用者。

現在，我還有一個叫編排MyCallerOrch這要由MyUsefulOrch提供有用的處理中受益。但是，MyCallerOrch位於不同的應用程序中，MyCallingApp。

我不希望有包含MyUsefulOrch從MyCallerOrch大會的任何引用。

我現在的問題是確保我可以從MyCallerOrch將消息發送到MyUsefulOrch並接收來自它的響應。

啊哈！相關性應該可以做到！但是，我如何才能在這種情況下獲得相關性？

例如：

• 我會把相關性id的屬性架構和東西公正的把它發送到MessageBox之前進入的GUID從MyCallerOrch這個屬性下的消息上下文？
• 如何確保MyCallerOrch只接收需要從MyUsefulOrch收到的答覆？
• 是否需要將關聯id值放入兩個業務流程之間發送的消息的消息正文中？

我非常感謝任何幫助，儘可能描述性地描述如何實現這一目標。

非常感謝提前。

Answer 1

我認爲你是在正確的軌道

在幾乎自2個應用程序將消息發送到海誓山盟，如果你使用強類型的模式，無論是應用程序將需要了解的模式。 在這種情況下，建議您將公共架構分離爲單獨的程序集，並從兩個編排應用程序中引用它。 （在服務器上註冊的模式必須具有唯一的XMLNS #ROOT，即使在多個應用程序中也是如此）

但是，如果您確實無法忍受共享模式程序集引用，則可能需要使用非類型化消息。

理查德Seroter有一個例子here

他的文章還介紹了汽車衝壓GUID的上下文屬性相關的技術。

編輯：好點。可以在沒有管道的情況下在消息上宣傳自定義上下文屬性 - 請參閱技巧here和here - 這足以將上下文屬性發送到MyUsefulOrch，並且類似地，可以在來自MyUsefulOrch內的返回消息上提升定製上下文MyUsefulOrch不需要任何關聯）。然而，我無法想象如何在返回MyCallingOrch時自定義上下文屬性可用於繼續「跟隨關聯」，除非您將新的相關屬性添加到返回消息中。

Answer 2

如果在調用程序業務流程中使用雙向請求/響應發送端口將消息發送到有用的業務流程，那麼可以使用相關性將相關消息路由回調用程序的用戶操作符。

訣竅是你需要修改有用的orch（當然，使它更有用）。

如果您不/無法控制用戶配置的呼叫者是否期待迴應，則需要將入站（請求）端口設置爲單向端口。然後通過發送到單向出站（響應）端口來完成編排。

爲確保從雙向/請求 - 響應調用方接收到的消息能夠正確路由回去，有用orch中出站消息的構造形狀將需要使用消息分配形狀將以下消息屬性設置爲true：

• BTS.RouteDirectToTP
• BTS.IsRequestResponse

之前設置這兩個屬性，不過，也確保在T像做msgOut(*) f= msgIn(*);他具有相同的消息分配形狀，以確保其他屬性被複制。如果入站和出站消息不相同，則必須一次一個地手動設置每個必需的屬性。

當然，除了上述兩個屬性之外，這些屬性有助於確保有用orch的結果正確路由給調用者。他們應該是你的相關集內，分別是：

• BTS.CorrelationToken
• BTS.EpmRRCorrelationToken
• BTS.IsRequestResponse
• BTS.ReqRespTransmitPipelineID
• BTS.RouteDirectToTP

我變得有點超前了，但是，因爲您將相關集分配給出站s只有在BTS.EpmRRCorrelationToken exists msgIn。這很關鍵。我用一個決定形式來表達一個決定，其決定基於那個確切的短語。如果結果爲真，則將先前構建的消息發送出，並將上面的相關集分配爲初始化相關集。這將導致BizTalk將消息路由回調用方作爲其預期響應。

如果決定的結果是錯誤的，那麼有用的編排的調用者是單向的。你仍然可能想發送一個結果（並且讓其他人訂閱它）。您甚至可以使用與雙向響應相同的發送端口，只需要而不是分配相關集。

當然，你會想徹底地測試這個。它在我使用它的一種情況下對我有用，但這並不能免除其他人的盡職調查。