【问题标题】:Correlation on MessageBox direct bound portsMessageBox 直接绑定端口的相关性
【发布时间】:2014-10-22 15:46:54
【问题描述】:

我有一个名为 MyUsefulOrch 的编排,托管在应用程序 MySharedApp 中。

MyUsefulOrch 有一个入站 messagebox-direct-bound 端口来接收请求,在做一些有用的工作后,一个 outbound messagebox-direct-bound 端口向调用者发送消息。

现在,我有另一个名为 MyCallerOrch 的编排,它希望从 MyUsefulOrch 提供的有用处理中受益。但是,MyCallerOrch 托管在不同的应用程序 MyCallingApp 中。

我不想从 MyCallerOrch 引用包含 MyUsefulOrch 的程序集。

我现在的问题是确保我可以从 MyCallerOrchMyUsefulOrch 发送消息并收到它的响应。

啊啊!相关性应该可以解决问题!但是在这种情况下,我该如何让相关性发挥作用呢?

例如:

  • 我是否会在属性模式中放入一个相关 id,然后在 MyCallerOrch 将它发送到消息框之前将一个 guid 填充到此属性下的消息上下文中?
  • 如何确保 MyCallerOrch 只收到它需要从 MyUsefulOrch 收到的响应?
  • 我是否需要将相关 id 值放入两个编排之间发送的消息的消息正文中?

对于如何实现这一点,我将非常感谢任何帮助,最好是尽可能描述性的。

非常感谢。

【问题讨论】:

    标签: biztalk correlation


    【解决方案1】:

    如果您在调用方编排中使用双向请求/响应发送端口将消息发送到有用编排,那么您可以使用关联将相关消息从调用方路由回有用编排。

    诀窍是您需要修改有用的 orch(当然是为了让它更有用)。

    如果您不/无法控制用户orch 的调用者是否期待回复,那么您需要将入站(请求)端口设置为单向端口。然后,编排将通过发送到单向出站(响应)端口来完成。

    为确保从双向/请求响应调用者收到的消息被正确路由回,您有用的 orch 内的出站消息的构造形状将需要使用消息分配形状将以下消息属性设置为 true:

    • BTS.RouteDirectToTP
    • BTS.IsRequestResponse

    不过,在设置这两个属性之前,还要确保在相同的消息分配形状中执行类似msgOut(*) f= msgIn(*); 的操作,以确保复制其他属性。如果入站消息和出站消息不同,则必须手动设置每个必需的属性,一次一个。

    当然,除了上述两个之外,这些属性有助于确保将有用的 orch 的结果正确路由到调用者。它们应该在您的相关集中并且是:

    • BTS.CorrelationToken
    • BTS.EpmRRCorrelationToken
    • BTS.IsRequestResponse
    • BTS.ReqRespTransmitPipelineID
    • BTS.RouteDirectToTP

    不过,我有点超前了,因为您仅在 BTS.EpmRRCorrelationToken exists msgIn 时才将相关集分配给出站发送形状。这很关键。我在管弦乐中使用了决策形状,决策基于该确切的短语。如果结果为真,则将先前构造的消息发送出去并将上面的相关集分配为初始化相关集。这将导致 BizTalk 将消息路由回调用方作为其预期响应。

    如果决定的结果是错误的,那么有用的编排的调用者是单向的。您仍然可能希望发送一个结果(并且只是让其他人订阅它)。您甚至可以使用与双向响应相同的发送端口,只需分配相关集。

    当然,您需要彻底测试一下。在我使用它的一种情况下,它确实对我有用,但这并不能免除其他人的尽职调查。

    【讨论】:

    • +1。这是非常高级的东西,但对于更强大的场景值得理解。
    • 我同意,尽管我认为它似乎更先进只是因为它的大部分(官方)没有记录。 :-)
    • 感谢您的回复 schellack。最后,通过初始化一个从未“使用”过的相关集,我能够在有用的 orch 响应消息中实现相关 guid 的提升。我得到了我想要的行为,虽然我还没有对多个调用者进行测试。
    【解决方案2】:

    我认为你几乎走在正确的轨道上

    由于 2 个应用程序将相互发送消息,如果您使用强类型架构,则两个应用程序都需要了解架构。 在这种情况下,建议您将通用架构分离到一个单独的程序集中,并从您的两个编排应用程序中引用它。 (在服务器上注册的模式必须具有唯一的 XMLNS#ROOT,即使跨多个应用程序)

    但是,如果您真的无法忍受共享模式程序集引用,您可能需要求助于非类型化消息。

    Richard Seroter 有一个例子here

    他的文章还解释了一种在上下文属性上自动标记相关 GUID 的技术。

    编辑:好点。可以在没有管道的情况下在消息上提升自定义上下文属性 - 请参阅技巧 herehere - 这足以将上下文属性发送到 MyUsefulOrch 并且类似地,可以在来自的返回消息上提升自定义上下文在 MyUsefulOrch 中(因为 MyUsefulOrch 不需要任何关联)。但是我想不出如何在返回 MyCallingOrch 时自定义上下文属性可用于继续“后续关联”,除非您在返回消息中添加新的关联属性。

    【讨论】:

    • 感谢您的回复。那么您是说我需要在某处使用管道以确保将相关 ID 提升到消息上下文?我正在使用直接绑定端口,因此没有可用的管道。顺便说一句,我可以愉快地引用一个共享模式 dll,因此不需要无类型的消息。
    • 好的,谢谢。在提升了我在请求中发送的 guid 之后,我使用了在来自有用 orch 的出站响应消息上初始化相关集的技巧。现在一切正常,调用者接收形状“跟随”相关集现在接收响应消息。我希望这将适用于多个呼叫者。我现在将对此进行测试。
    • 为了让大家知道,这适用于多个并发调用者。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-11-15
    • 1970-01-01
    相关资源
    最近更新 更多