如何在行程安排中使用BRE解决转换服务? [英] How to Resolve a Transformation Service with BRE that occurs after an Orchestration in an Itinerary?
问题描述
在尝试与Biztalk ESB Toolkit 2.0实现简单的集成模式时，我遇到了一个问题，即试图解决编排后发生的转换行程服务.
我正在使用BRE Resolver执行规则，这些规则需要检查Context Message Type属性来确定要使用的适当映射.但是，一旦消息到达与转换服务关联的行程中的步骤，该映射将无法执行.
经过仔细的调查，似乎消息类型没有提供给BRE解析器内部使用的解决方案"对象.实际上，由于离开先前业务流程的消息的类型为System.Xml.XmlDocument，因此消息的类型是从上下文降级"的.
通过跟踪规则引擎的执行，我可以观察到到达BRE解析器时，消息的类型确实是丢失.消息的类型为空，而文档的强类型为Microsoft.XLANGs.BaseTypes.Any.
我使用的Orchestration服务直接来自ESB Toolkit 2.0附带的示例.
在行程中的编排后 之后，有没有办法执行基于上下文的BRE解析?
简而言之，关键是推论原始消息的上下文并提升MessageType上下文属性.在以下段落中，我将在我的博客上重现即将发表的帖子:编排行程服务101
在努力使之工作并尝试不同的解决方案之后，我终于成功遵循了一套简单的规则.在这篇文章中，我想概述什么构成了一个行为举止良好的ESB Toolkit 2.0友好编排，该编排可用作行程服务，并且仍然利用Business Rules Engine解析器基于消息的上下文类型进行动态转换.
行程服务的上下文订阅
首先，旨在用作行程服务的业务流程需要具有直接绑定的逻辑端口，该端口必须链接到定义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类型的消息.确实，如果不是这种情况，那么编排将无法执行，并且 Routing Failure 错误消息将被注册到 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属性.通过在业务流程结束时初始化发送形状上的相关性，可以轻松实现这一点. 在原始消息中提升消息类型是我最初尝试中所缺少的.一旦确定了这一点，行程就像一个魅力！ 尽管事后看来解决方案似乎很明显，但如果我早一点知道，那肯定会对我有帮助.我希望这篇文章能对遇到同样问题的人有所帮助. In trying to implement simple integration patterns with Biztalk ESB Toolkit 2.0, I'm facing a problem trying to resolve a Transformation Itinerary Service that occurs after an Orchestration. I'm using the BRE Resolver to execute rules that need to inspect the Context Message Type property to determine the appropriate map to use. However, once the message reaches the step in the Itinerary associated with the Transformation Service, the map fails to execute. From careful investigation, it appears that the message type is not supplied to the "Resolution" object that is used internally by the BRE resolver. Indeed, since the message leaving the preceding Orchestration is typed By tracking rules engine execution, I can observe that the type of the message is indeed lost when reaching the BRE resolver. The type of the message is empty, whereas the strongly-typed of the document is The Orchestration service that I use is taken straight from the samples that ship with ESB Toolkit 2.0. Is there a way to perform Context-Based BRE resolution after an Orchestration in an Itinerary? Answering my own question... in short, the key is to preverse the context of the original message and to promote the MessageType context property. In the following paragraphs, I reproduce a forthcoming post on my blog: Orchestration Itinerary Service 101 After struggling to make this work and trying different solutions, I finally succeeded with a set of simple rules to follow. In this post, I would like to outline what constitutes a well-behaved ESB Toolkit 2.0-friendly orchestration that can be used as an Itinerary service and still take advantage of the Business Rules Engine Resolver for dynamic transformation based upon the context type of a message. Context Subscription for an Itinerary Service First, an orchestration designed to be used as an Itinerary service need to have a direct-bound logical port, linked to a receive shape that defines a ESB-friendly subscription like so: The documentation does not mention this, but this makes it clear that the direct-bound port operations need to be mapped to messages of type System.Xml.XmlDocument. Indeed, if that is not the case, the orchestration will fail to be executed and a Routing Failure error message will be registered to the Message Box. Incidentally, this means that the very type of a message does not enter into account at all. And this largely explains why, after execution of the orchestration, the Business Rules Engine resolver fails to determine the correct transformation. Getting at the Itinerary The following code in an Expression Shape at the beginning of the orchestration helps retrieve the current Itinerary step: Preserving the Context of the Original Message Next, the context of the original message must be preserved (for the most part) at each step of the orchestration. This is of particular importance when having several intermediate construct shapes in the orchestration to carry out the specific scenario at hand. Notice that I wrote "for the most part" in the sentence above. In fact, as we'll see in a minute, the type of the resulting message need to be present in the context at the end of the orchestration. Most probably, this will be a different type than the original inbound message. And since assigning to the read-only BTS.MessageType property is not possible, this can be quite tricky to achieve sometimes. You might have to resort to execute a custom pipeline inside the orchestration or other exotic techniques for this to be the case. Most of the times, however, the syntax shown above should work. Advancing the Itinerary The following very straightforward code must not be forgotten at the end of the orchestration: Promoting Context Properties The documentation does not spell out quite cleary what exact steps must be followed, or even if properties need to be promoted from such an orchestration, but looking at the samples provided as source code, one can find that the following properties take part in the resolution mechanism: However, in the scenario outlined in this post this is definitely not enough. For context-based rules to work after the orchestration, the BTS.MessageType property need to be promoted as well. This can be easily achieved by initializing a correlation on the send shape at the end of the orchestration. And it works! Promoting the message type in the context of the resulting message was what was missing in my original attempt. Once this was identified, the itinerary worked like a charm ! Even though the solution might seem obvious after the fact, it sure would have helped me if I had known that earlier. I hope this post will help those hitting the same problem. 这篇关于如何在行程安排中使用BRE解决转换服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！System.Xml.XmlDocument, the type of the message is "demoted" from the context.Microsoft.XLANGs.BaseTypes.Any.Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"
// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);
OutboundMessage(*) = SourceMessage(*)
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);
