Ожидание async taks в SQL Server Service Broker

Question

Я изучаю SQL Server Service Broker как инструмент для координации задач async. Предположим, у меня есть MasterService, который объединяет данные от EmployeeInfoService и PayrollInfoService. Я получаю список EmployeeIDs, а затем отправляю каждого в качестве разговора в обе службы. В конце этих двух сервисов активируется sproc, который будет обрабатывать два EmployeeIDs за раз.

Пара вопросов

1. Как я могу хранить ответы для каждого сотрудника INTO временных таблиц внутри моей MasterService?
2. Как узнать, что две службы обработали все EmployeeIDs, чтобы я мог генерировать данные из двух темных таблиц, которые я построил на шаге 1?

Вот мой код до сих пор:

-- Get a whole bunch of EmployeeIDs 

DECLARE @EmployeeConversation uniqueidentifier 
DECLARE @PayrollConversation uniqueidentifier 

BEGIN DIALOG @EmployeeConversation 
    FROM SERVICE MasterService 
    TO SERVICE  'EmployeeInfoService'; 

    SEND ON CONVERSATION @EmployeeConversation MESSAGE (EmployeeID1) 
    SEND ON CONVERSATION @EmployeeConversation MESSAGE (EmployeeID2) 
    SEND ON CONVERSATION @EmployeeConversation MESSAGE (Employee...); 

BEGIN DIALOG @PayrollConversation 
    FROM SERVICE MasterService 
    TO SERVICE  'PayrollInfoService' 
    WITH RELATED_CONVERSATION_GROUP = @EmployeeConversation; 

    SEND ON CONVERSATION @PayrollConversation MESSAGE (EmployeeID1) 
    SEND ON CONVERSATION @PayrollConversation MESSAGE (EmployeeID2) 
    SEND ON CONVERSATION @PayrollConversation MESSAGE (Employee...); 

-- Now I need to wait till both conversations are done. 
-- How do I handle that? 

Answer 1

Теперь мне нужно ждать, пока обе беседы сделали.

Нет, вы этого не сделаете. Это самая важная часть для ориентированного на сообщение программирования: вы никогда не возвращаетесь wait для ответа. Ответ может наступить через секунду, или это может произойти через неделю. Что вы делаете, так это завершение обработки, вот и все. Когда ответ приходит от службы, вы получаете активацию, и вы обрабатываете ответ.

Так что в вашем случае, если вы связать процедуру с MasterService очереди:

create procedure usp_masterService 
as 
begin transaction 
receive message_body, messge_type from MasterServiceQueue; 
if message_type = 'EmployeeInfoMessage' then 
    insert or update into stateTable info from message body; 
if message_type = 'PayrollInfoMessgae' then 
    insert or update into stateTable info from message body; 
if allResponsesReceived 
    do something 
... 
commit 

alter queue MasterServiceQueue with activation (procedure usp_masterService); 

Как вы справляетесь состояние, связанное с инфо-запросов сотрудников и как обнаружить «все полученные ответы» полностью бизнес-логика. Но вы не можете использовать временные таблицы, ответы будут обрабатываться различными транзакциями по различным потокам (активированные процедуры) и, самое главное, они могут обрабатываться через перезапуск сервера.

Ваш поток должен любезно обрабатывать случай, когда «PayrollInfoService» удален (на другой машине) и сейчас находится на 6 часов обслуживания. Ваши приговоры придут, но займет 6 часов. Как вы можете разоблачить это в пользовательском интерфейсе приложения, будет зависеть от случая к случаю. Но думайте об отключенных, слабосвязанных, неинтерактивных сервисах.