协调中的促销财产

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。

总之，每当它没有按照您期望的方式进行布线时，总是检查消息的上下文属性。