Sql server ServiceBroker消息流

我在两个位置有两台不同的服务器。我需要使用异步数据交换

服务器A是我们的数据服务器，我们在这里存储客户信息。 服务器B是我们的处理服务器，我们处理生产。 服务器B上的每个生产操作都有一个生产组。我需要做的是：

A向B发送一条带有问题的消息：此groupGUID中今天计划进行哪些操作。 B必须回答今天计划的XML操作列表。 A必须用要取消的操作的XML列表来回答 B必须取消操作并结束对话 我的问题是：正确的方法是什么？我可以用一个合同在一个对话框中完成这项工作吗？我应该吗

有这样的合同：

CREATE CONTRACT [GetScheduledContract] 
AUTHORIZATION [xxx]
(GetScheduledOutCalls SENT BY INITIATOR,
ReturnScheduledOutCalls SENT BY TARGET,
DeleteScheduledOutCalls SENT BY INITIATOR)

---

或者我应该将任务分为不同的合同和对话框吗？

我认为你作为MVP的能力很好，也就是说，如果一切顺利，它就会起作用。有几件事：

考虑从目标添加另一个答复，表示操作在关闭会话之前成功完成。收到后，发起者还可以关闭其终端。 如果这些操作中的任何一个明显无法完成，例如在步骤4中，请求删除不存在的内容或删除导致外键冲突，会发生什么情况？我会添加一些由任何一方发送的错误消息类型，允许任何一方告诉另一方嘿…出了什么问题。 如果这些操作中的任何一个隐式无法完成（例如，消息从未传递），会发生什么情况？另一方可能出于某种原因而不作出回应。以某种方式构建，至少可以检测并提醒用户。

---

Re 1，我认为发起人最好在收到结束对话或SB错误消息后结束对话，而不是在收到结果消息时结束对话。目标发送的消息类型可用于每个或所有取消操作的成功和错误结果。目标通常不关心发起方是否出现问题，因为这通常是由消费者提供的。健壮的SB设计的最大挑战可能是使用异步消息处理和/或监视不愉快的路径。如果不是这样，我道歉。正如OP所述，可能是发起者在发送订单取消请求后结束了他们这一方的对话。通过让目标方确认，它允许更健壮的处理。完全同意目标方应该首先结束对话。是一种应该避免的反模式。