我有一个名为 MyUsefulOrch 的业务流程，托管在应用程序 MySharedApp 中。
MyUsefulOrch 有一个入站消息箱直接绑定端口来接收请求，并在完成一些有用的工作后，出站消息箱直接绑定端口向呼叫者发送消息。
现在，我有另一个名为 MyCallerOrch 的业务流程，它希望受益于 MyUsefulOrch 提供的有用处理。但是， MyCallerOrch 托管在另一个应用程序 MyCallingApp 中。
我不想对 MyCallerOrch 中包含 MyUsefulOrch 的程序集进行任何引用。
我现在的问题是确保我可以从 MyCallerOrch 向 MyUsefulOrch 发送消息并从中收到回复。
AHAH！相关应该成功！但是，如何在这种情况下获得相关性呢？
例如：
我非常感谢有关如何实现这一目标的任何帮助，理想情况下尽可能具有描述性。
非常感谢提前。
答案 0 :(得分：3)
如果您在调用者业务流程中使用双向请求/响应发送端口将消息发送到有用的业务流程，那么您可以使用相关将相关消息路由回调用方的用户orch。
诀窍是你需要修改有用的orch（当然是为了使它更有用）。
如果您不能/无法控制用户orch的呼叫者是否期望回复，那么您需要使入站（请求）端口成为单向端口。然后，编排将通过发送到单向出站（响应）端口来完成。
要确保从双向/请求 - 响应调用方接收的消息正确路由，有用的orch中的出站消息的构造形状将需要使用消息分配形状将以下消息属性设置为true： / p>
BTS.RouteDirectToTP BTS.IsRequestResponse 在设置这两个属性之前，还要确保在相同的消息分配形状中执行msgOut(*) f= msgIn(*);之类的操作，以确保复制其他属性。如果入站和出站邮件不相同，则必须手动设置每个必需的属性，一次一个。
当然，除了上述两个属性之外，这些属性有助于确保将有用的orch的结果正确地路由到调用者。它们应该在您的相关集内，并且是：
BTS.CorrelationToken BTS.EpmRRCorrelationToken BTS.IsRequestResponse BTS.ReqRespTransmitPipelineID BTS.RouteDirectToTP 然而，我正在领先于自己，因为只有在BTS.EpmRRCorrelationToken exists msgIn时才将相关集分配给出站发送形状。这很关键。我在orchcestration中使用了一个决策形状，决定基于那个确切的短语。如果结果为true，则将先前构造的消息发送到，并将上面的相关集分配为初始化相关集。这将导致BizTalk将消息路由回调用者作为其预期响应。
如果决定的结果是错误的，那么有用的编排的调用者是单向的。您仍然可能希望发送结果（并且只是让其他人订阅它）。您甚至可以使用与双向响应相同的发送端口，只需执行 not 分配相关集。
当然，您需要彻底测试这一点。在我使用它的一种情况下，它确实对我有用，但这并不能免除其他人的尽职调查。
答案 1 :(得分：1)
我认为你几乎走在正确的轨道上
由于2个应用程序将向彼此发送消息，因此如果使用强类型模式，则两个应用程序都需要了解模式。 在这种情况下，建议您将公共模式分离到单独的程序集中，并从两个编排应用程序中引用它。 （在服务器上注册的模式必须具有唯一的XMLNS＃ROOT，甚至跨多个应用程序）
但是，如果您实际上无法忍受共享架构程序集引用，则可能需要使用无类型消息。
Richard Seroter有一个例子here
他的文章还解释了一种在上下文属性上自动标记关联GUID的技术。
编辑：好点。可以在没有管道的情况下在消息上提升自定义上下文属性 - 请参阅技巧here和here - 这足以将上下文属性发送到MyUsefulOrch，同样，可以提升自定义上下文MyUsefulOrch中的返回消息（因为MyUsefulOrch不需要任何关联）。但是，我无法想到，在返回MyCallingOrch时，自定义上下文属性可用于继续“以下关联”，除非您在返回消息中添加新的关联属性。