2

我读到我们可以在编排中提升属性。以下是我的步骤 -

  1. 创建一个新的“StudentID”推广属性。
  2. 更改值“MessageContextPropertyBase”。
  3. 更新编排中“StudentID”的值。
  4. 创建一个新的“StudentID”相关集。
  5. 初始化发送形状的相关集。
  6. 在 BizTalk 管理员控制台中创建发送端口。
  7. 设置过滤器 "POC.PromotedProINOx.Schema.PropertySchema.StudentID == "7" "

我没有错误。但我希望如果“StudentID”为 7，那么它应该被订阅。

问题- 我认为它没有检查“StudentID”的值，因为消息文件总是放在 out 文件夹中。

我错过了什么吗？

4

1 回答 1

1

您可能缺少几件事

  1. 如果接收端口上的消息具有具有相同提升属性且正确 StudentID 为 7 的消息，则编排和发送端口都将订阅它。因此，如果您将 StudentID 设置为 Orchestration 中的其他内容，则您通过发送端口发送的消息实际上并未通过 Orchestration，而是直接来自接收端口。
    修复：将接收到的消息的值设置为其他值，或者在入站消息上没有提升的属性。

  2. 您已在编排中指定稍后指定的逻辑端口，然后将其绑定到发送端口。默认情况下，发送端口始终订阅其唯一 ID。当业务流程通过绑定到发送端口的逻辑端口发布消息时，它会在发布消息时设置并提升该 ID。即使添加订阅规则也只是意味着它会将其视为BTS.SPID = {id} OR {your rule}. 这意味着即使 StudentID 与发送端口上的订阅规则不匹配，它也会匹配 SPID 并仍会接收它。
    修复：将编排中的逻辑端口更改为直接绑定。

  3. 第三种可能性是，从编排中，您发布的消息实际上的 StudentID 为 7。
    修复：检查您构造的形状（映射和分配）以确保您实际上将其设置为另一个值。确保发送形状中指定的消息实际上是使用新值构造的消息。

分析问题的方法是查看通过发送端口的消息的上下文属性，方法是在管道之前启用属性跟踪，或者通过停止（但不是取消登记）发送端口并查看上下文挂起消息的属性。

如果通过发送端口的消息的 StudentID = 7，那么您已经完成了 #3 或 #1，请参见下文。

如果消息包含接收端口的详细信息以及 StudentID，则它直接来自接收端口（根据 #1）。但是，我希望当 Orchestration 尝试发布具有不同 StudentID 的消息时会出现错误，除非 Orchestration 甚至没有运行（查看跟踪的实例）或见下文。

如果通过发送端口的消息具有 BTS.SPID 的提升属性，则逻辑端口按照 #2 绑定到发送端口。

如果您每输入一条消息就会收到两条消息，那么您将获得上述每条消息之一，并且已经完成了 #1 和 #2。

总而言之，只要消息没有按照您期望的方式进行路由，请始终检查消息的上下文属性。

于 2016-06-13T11:06:58.627 回答