如果消息是由触发器发送的，在对话 FROM SERVICE 参数中设置什么？

如何解决如果消息是由触发器发送的，在对话 FROM SERVICE 参数中设置什么？

我有将消息发送到 Service broker Service 的数据库触发器。要发送消息，必须首先创建对话，因为这就是 Service broker 的工作方式（在服务之间的对话中发送消息）。我读到应该重用对话，因为每次创建新对话都会对性能产生不良影响，并且对话数量可能会增加很多。无论我是否会重复使用对话，我都必须至少创建第一个对话。开始对话具有以下语法：

BEGIN DIALOG [ CONVERSATION ] @dialog_handle  
   FROM SERVICE initiator_service_name  
   TO SERVICE 'target_service_name'  
       [,{ 'service_broker_guid' | 'CURRENT DATABASE' }]   
   [ ON CONTRACT contract_name ]  
   [ WITH  
   [  { RELATED_CONVERSATION = related_conversation_handle   
      | RELATED_CONVERSATION_GROUP = related_conversation_group_id } ]   
   [ [,] LIFETIME = dialog_lifetime ]   
   [ [,] ENCRYPTION = { ON | OFF }  ] ]  
[ ; ]  

我不知道应该在 FROM SERVICE 参数中设置什么。通常，Service broker 对话是双向的。我想从触发器向服务发送消息，我不想得到任何反馈，我只想在一个方向上发送消息。我在 FROM SERVICE 参数中设置了目标服务并且它有效，但我不确定这是否是好的做法。我是否应该创建附加服务并将其设置在 FROM SERVICE 参数中，以便从我的触发器中使用对话？也许这个服务应该有一个激活程序，如果 EndDialog 消息到达，则结束对话？

我不希望目标服务有任何响应是一种很好的做法吗？我知道我可以收到一些管理消息，例如 http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog 或 http://schemas.microsoft.com/SQL/ServiceBroker/Error。我的印象是 Service broker 强制使用双向对话。

解决方法

Service Broker 需要为发起方和目标方提供服务。您的触发器是来自发起方服务，因此您应该为此创建一个服务和队列。但是触发器不需要实现从发起者队列接收消息。

您可以有一个单独的进程（可能是一个预定的批处理进程）来监视发起方队列中的意外错误和结束对话消息，并且可能在需要时开始一个新的长时间运行的对话。