協調中的促銷財產

Question

我已閱讀有關我們可以在協調中促進財產的內容。以下是我的步驟 -

1. 創建一個新的「StudentID」提升的屬性。
2. 更改值「MessageContextPropertyBase」。
3. 更新編排中「StudentID」的值。
4. 創建一個新的「StudentID」關聯集。
5. 初始化發送形狀的相關集。
6. 在BizTalk管理員控制檯中創建一個發送端口。
7. 設置一個過濾器 「POC.PromotedProINOx.Schema.PropertySchema.StudentID == 」7「，」

我得到任何錯誤。但我希望如果「StudentID」是7，那麼它應該訂閱。

問題 - 我認爲它沒有檢查「StudentID」的值，因爲消息文件總是放在out文件夾中。

我錯過了什麼嗎？

Answer 1

有可能是你缺少

1. 幾件事情如果消息接收端口有有7個正確StudentID同樣提升屬性的消息，無論是編排和發送端口將認購到它。因此，如果您在編排中將StudentID設置爲其他內容，則您通過發送端口發送的消息實際上並不通過編排，而是直接來自接收端口。
   修復：將收到的消息的值設置爲 ，或者沒有入站消息的提升屬性。

2. 您已指定業務流程中的邏輯端口以稍後指定，然後將其綁定到發送端口。默認情況下，發送端口始終訂閱其唯一ID。當編排通過綁定到發送端口的邏輯端口發佈消息時，它在發佈消息時設置並提升該ID。即使添加訂閱規則也意味着它會將其視爲BTS.SPID = {id} OR {your rule}。這意味着，即使StudentID與發送端口上的訂閱規則不匹配，它也會匹配SPID並仍然選取它。
   解決方法：將Orchestration中的邏輯端口更改爲Direct Bound。

3. 第三種可能性是，從您要發佈但實際上確有7
   修復的StudentID業務流程的消息：檢查您構建的形狀（地圖&分配），以確保您實際上是將它設置到另一個值。確保發送形狀中指定的消息實際上是使用新值構造的消息。

分析問題的方法是看即通過發送端口去，或者通過管道之前使屬性的跟蹤消息的上下文屬性，或停止（但不是Unenlisting）的發送端口並查看暫停消息的上下文屬性。

如果通過發送端口發送的消息具有StudentID = 7，那麼您已經完成了＃3或＃1，如下所示。

如果該消息包含接收端口以及StudentID的詳細信息，則該消息根據＃1直接來自接收端口。然而，我希望從Orchestration中發現一個錯誤，試圖發佈帶有不同StudentID的消息，除非Orchestration甚至沒有運行（查看跟蹤的實例）或下面的內容。

如果通過發送端口的消息具有BTS.SPID的提升屬性，則邏輯端口根據＃2綁定到發送端口。

如果您收到每條您輸入的兩條消息，則您將擁有以上每條消息中的一條，並且已經完成＃1 &＃2。

總之，每當它沒有按照您期望的方式進行佈線時，總是檢查消息的上下文屬性。