如何解决行程中编排后发生的 BRE 转换服务？

发布于 2024-09-05 12:42:08 字数 482 浏览 5 评论 0原文

在尝试使用 Biztalk ESB Toolkit 2.0 实现简单的集成模式时，我在尝试解决编排后发生的转换行程服务时遇到了问题。

我使用 BRE 解析器来执行需要检查上下文消息类型属性以确定要使用的适当映射的规则。但是，一旦消息到达与转换服务关联的行程中的步骤，地图将无法执行。

通过仔细调查，消息类型似乎未提供给 BRE 解析器内部使用的“Resolution”对象。实际上，由于离开前面的 Orchestration 的消息的类型为 System.Xml.XmlDocument，因此该消息的类型已从上下文中“降级”。

通过跟踪规则引擎执行，我可以观察到消息类型在到达 BRE 解析器时确实丢失。消息的类型为空，而文档的强类型为 Microsoft.XLANGs.BaseTypes.Any。

我使用的编排服务直接取自 ESB Toolkit 2.0 附带的示例。

有没有办法在行程中的编排之后执行基于上下文的 BRE 解析？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

彡翼 2024-09-12 12:42:08

回答我自己的问题...简而言之，关键是反转原始消息的上下文并提升 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 类型的消息。事实上，如果不是这种情况，编排将无法执行，并且路由失败错误消息将被注册到消息框。

顺便说一句，这意味着消息的具体类型根本不考虑在内。这在很大程度上解释了为什么在执行编排之后，业务规则引擎解析器无法确定正确的转换。

获取行程

编排开始时表达式形状中的以下代码有助于检索当前行程步骤：

// 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);

提升上下文属性

com/en-us/library/ff699631(v=BTS.70).aspx" rel="nofollow noreferrer">文档没有明确说明必须遵循的确切步骤，或者即使属性需要可以从这样的编排中进行提升，但是查看作为源代码提供的示例，可以发现以下属性参与了解析机制：

推广属性 http://public.blu.livefilestore.com/y1pLURN1zH2vdRuLcF5y yAiHZQQ9rkdlrqG-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

尽管解决方案在事后看起来似乎很明显，但如果我早点知道的话，它肯定会对我有所帮助。我希望这篇文章能够帮助那些遇到同样问题的人。

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:

Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"

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:

// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);

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.

OutboundMessage(*) = SourceMessage(*)

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:

itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);

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:

Promoting Properties http://public.blu.livefilestore.com/y1pLURN1zH2vdRuLcF5yyAiHZQQ9rkdlrqG-QH01Nn8hEY5zH1W9TjjtNc0Z9421eFC2gUVG-srs2-NdcliI3XD1w/orchestration_service_promoting_properties.png?psid=1

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.

Message Type Correlation http://public.blu.livefilestore.com/y1pQb-dkmbNBcur7CwdyudiIE9EMKGnZ0LoGuFpfDLseAWsiUz9C1EC1ZR5pn0gI4tgr3syEN2y-cfPB9EgEzlgtA/message_type_correlation.png?psid=1

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 !

Rule Firing Log http://public.blu.livefilestore.com/y1pGVViJM7SFbopcnYODHkqGUbkgS1RQR8a7ASVsNVDu8Krdhb_Vyj4PugbMPSFcfMEZ1P_3a7It0QQpXdF_dnvDg/rule_firing_log.png?psid=1

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.

回复收藏 0 原文

~没有更多了~