在尝试使用 Biztalk ESB Toolkit 2.0 实现简单的集成模式时，我在尝试解决在编排之后发生的转换路线服务时遇到了问题。
我正在使用 BRE 解析器来执行需要检查上下文消息类型属性以确定要使用的适当映射的规则。但是，一旦消息到达与转换服务关联的路线中的步骤，地图将无法执行。
从仔细调查来看，消息类型似乎没有提供给 BRE 解析器内部使用的“解决方案”对象。实际上，由于离开前一个编排的消息是 typed System.Xml.XmlDocument，因此消息的类型从上下文中“降级”了。
通过跟踪规则引擎的执行，我可以观察到消息的类型在到达 BRE 解析器时确实丢失了。消息的类型是空的，而文档的强类型是Microsoft.XLANGs.BaseTypes.Any.
我使用的编排服务直接取自 ESB Toolkit 2.0 附带的示例。
有没有办法在行程中的编排之后执行基于上下文的 BRE 解析？
回答我自己的问题……简而言之，关键是要逆向原始消息的上下文，并提升 MessageType 上下文属性。在以下段落中，我在我的博客上复制了一篇即将发布的帖子：
编排行程服务101
在努力完成这项工作并尝试了不同的解决方案之后，我终于成功地遵循了一套简单的规则。在这篇文章中，我想概述一个行为良好的 ESB Toolkit 2.0 友好编排的构成，它可以用作行程服务，并且仍然利用业务规则引擎解析器根据消息的上下文类型进行动态转换.
行程服务的上下文订阅
首先，设计用作行程服务的编排需要具有直接绑定的逻辑端口，链接到定义 ESB 友好订阅的接收形状，如下所示：
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"
文档没有提到这一点，但这清楚地表明直接绑定端口操作需要映射到 System.Xml.XmlDocument 类型的消息。实际上，如果不是这种情况，编排将无法执行，并且将向Message Box注册路由失败错误消息。
顺便说一句，这意味着根本不考虑消息的类型。这在很大程度上解释了为什么在执行编排之后，业务规则引擎解析器无法确定正确的转换。
了解行程
编排开始处的表达式形状中的以下代码有助于检索当前的行程步骤：
// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);
保留原始消息的上下文
接下来，必须在编排的每个步骤中（大部分）保留原始消息的上下文。当编排中有多个中间构造形状以执行手头的特定场景时，这一点尤为重要。
OutboundMessage(*) = SourceMessage(*)
请注意，我在上面的句子中写了“大部分”。事实上，正如我们稍后将看到的，生成的消息的类型需要在编排结束时出现在上下文中。很可能，这将是与原始入站消息不同的类型。而且由于无法分配给只读的BTS.MessageType属性，因此有时很难实现。
您可能不得不求助于在编排中执行自定义管道或其他奇特的技术来实现这种情况。然而，大多数时候，上面显示的语法应该可以工作。
推进行程
在编排结束时一定不能忘记以下非常简单的代码：
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);
提升上下文属性
该文档并没有清楚地说明必须遵循哪些确切步骤，或者即使需要从这种编排中提升属性，但是查看作为源代码提供的示例，可以发现以下属性参与了解决方案机制：
但是，在这篇文章中概述的场景中，这绝对是不够的。
为了在编排之后基于上下文的规则起作用，还需要提升 BTS.MessageType 属性。这可以通过在编排结束时初始化发送形状的相关性来轻松实现。
它有效！
在结果消息的上下文中提升消息类型是我最初尝试中缺少的。一旦确定了这一点，行程就像一个魅力！
尽管解决方案在事后可能看起来很明显，但如果我早点知道它肯定会对我有所帮助。我希望这篇文章能帮助那些遇到同样问题的人。
