在努力实现与BizTalk ESB工具包2.0整合方式简单，我面临的一个问题试图解决一个业务流程之后发生了转变行程服务。
我使用的是BRE解析器执行需要检查上下文消息类型属性来确定相应的地图使用规则。 然而，一旦该消息到达与转换服务相关联的行程的步骤中，在地图上无法执行。
从缜密侦查，看来该消息类型没有被提供给一个由BRE解析器内部使用的“解决方案”对象。 实际上，由于在离开前述编排消息被键入System.Xml.XmlDocument ，消息的类型是从上下文中，“降级”。
通过跟踪规则引擎执行，我可以观察到，在到达BRE解析器当消息的类型确实丢失 。 的类型的信息是空的，而强类型的文件是Microsoft.XLANGs.BaseTypes.Any 。
我使用的业务流程服务是从与ESB工具包2.0附带的样本直取。
是否有一个行程的业务流程后进行基于上下文的BRE解决的方法吗？
回答我的问题......总之，关键是要preverse原始消息的背景下，为了促进消息类型上下文属性。 在下面的段落中，我就复制一个即将到来的职位我的博客 ：
编排行程服务101
努力使这项工作，并尝试不同的解决方案之后，我终于成功了一套简单的规则可循。 在这篇文章中，我想概括什么是乖巧的ESB工具包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类型的邮件。 事实上，如果不是这样，业务流程将无法执行，一个路由故障错误信息将被注册到消息框 。
顺便说一句，这意味着很有型的消息不进入帐户所有。 而这在很大程度上解释了为什么，业务流程的执行后，业务规则引擎解析无法确定正确的转换。
获取的行程
在业务流程的开始的表达式形状下面的代码可以帮助检索当前行程的步骤：
// 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);
促进上下文属性
该文件并没有说明相当克利必须遵循的具体步骤，或者即使性能需要从这样的编排推广，但看着作为源代码提供的样品，可以发现以下属性决议参加机制：
提升属性http://public.blu.livefilestore.com/y1pLURN1zH2vdRuLcF5yyAiHZQQ9rkdlrqG-QH01Nn8hEY5zH1W9TjjtNc0Z9421eFC2gUVG-srs2-NdcliI3XD1w/orchestration_service_promoting_properties.png?psid=1
然而，在这篇文章中概述的情景，这是绝对不够的。
对于基于上下文的规则编排后工作，BTS.MessageType财产需要促进为好。 这可以通过在业务流程的结束初始化上发送形状的相关性来容易地实现。
消息类型相关http://public.blu.livefilestore.com/y1pQb-dkmbNBcur7CwdyudiIE9EMKGnZ0LoGuFpfDLseAWsiUz9C1EC1ZR5pn0gI4tgr3syEN2y-cfPB9EgEzlgtA/message_type_correlation.png?psid=1
和它的作品！
促进结果消息的情况下消息类型是什么在我原来的尝试失踪。 一旦被确定，行程工作就像一个魅力！
规则触发日志http://public.blu.livefilestore.com/y1pGVViJM7SFbopcnYODHkqGUbkgS1RQR8a7ASVsNVDu8Krdhb_Vyj4PugbMPSFcfMEZ1P_3a7It0QQpXdF_dnvDg/rule_firing_log.png?psid=1
即使解决方案可能在事后看起来很明显，它肯定会帮助我，如果我早知道早。 我希望这篇文章将帮助那些击中了同样的问题。
