不同服务器中两个 Biztalk 编排之间的同步请求响应
我有一个公开 Web 服务的编排，它检查收到的消息的来源，基于该消息执行一些分支逻辑，并调用一组“服务”编排中的一个（驻留在不同的应用程序中）。这些服务编排对我的消息执行一些更新，然后在完成后将其发送回路由编排。然后路由应用程序发送适当的 Web 服务响应。即端到端过程都是同步的。
我的目的是在“路由”编排上有一个直接绑定的发送/接收端口，在“服务”编排上有一个链接的接收/发送端口以实现阻塞，但我在完成这项工作时遇到了麻烦。
我尝试过使用相关性和过滤表达式，但当服务编排尝试发回其响应时，我始终看到“多个订阅者错误”。
我确保没有其他编排/端口正在使用我的架构（以确保创建一个全新的编排/端口）。
对此我有点抓狂，这似乎是一件相对容易完成的事情。
（ps，我倾向于让服务编排公开一个 Web 服务并调用它，但对于始终驻留在同一台计算机上的东西来说，这似乎还有很长的路要走）。
I have an orchestration which exposes a web service, it examines the source of the message received executes some branching logic based on that and calls one of a set of 'service' orchestrations (which resides in a different Application). These service orchestrations perform some update on my message then send it back to the routing orchestration when complete. The routing application then sends an appropriate web service response. i.e the end to end process is all meant to be synchronous.
My intention was to have a direct bound send/receive port on my 'routing' orchestration and a linked receive/send port on the 'service' orchestrations to achieve the blocking, but I'm having trouble making this work.
I've tried using correlations and filter expressions but I'm consistently seeing the 'Multiple Subscribers error' when the Service orchestration tries to send back its response.
I've ensured that no other orchestrations/ports are using my Schema (to the point of creating a brand new one to be sure).
Tearing my hair out over this a bit, It seems like something which should be relatively straightforward to accomplish.
(p.s I'm leaning towards having the service orchestrations expose a web service and calling that, but it seems like a long way around for something which is always going to reside on the same machine).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
确保消息被 biztalk 视为“不同”以便不会发生此类问题的常见方法是使用仅上下文属性，该属性在前后设置为不同的值，然后使用相关性和过滤表达式确保消息一次仅匹配来自特定位置的消息的特定实例。
这样，即使消息类型相同，订阅也不会真正具有相同的谓词。
A common way to ensure that messages are seen as "different" by biztalk so that this kind of issues don't happen is to use a context-only property that gets set to different values before and after, and then use correlations and filter expression to make sure that the messages match only a specific instance of the message coming from a specific location at a time.
That way, even if the message types are the same, the subscriptions won't really have the same predicates.