У меня есть стандартное приложение Azure Logic App. Это имеет два рабочих процесса; RunBre и StubSatellite.
Желаемый поток взаимодействия показан на следующей диаграмме:
Рабочий процесс RunBre генерирует руководство в качестве идентификатора сеанса. Затем он публикует это в теме служебной шины:
Это сообщение правильно обрабатывается рабочим процессом StubSatellite:
Проверив приложение логики, историю запусков и обозреватель служебной шины, я вижу, что сообщение с тем же идентификатором сеанса, сгенерированное RunBre, правильно публикуется в очереди ответов рабочим процессом StubSatellite. Кроме того, исследование служебной шины показывает активный сеанс в очереди ответов с правильным идентификатором сеанса.
Моя проблема возникает, когда рабочий процесс RunBre пытается использовать ответное сообщение из очереди. Я использую встроенное действие «Получить сообщения из сеанса очереди». Я передаю ему правильный идентификатор сеанса в качестве параметра, но он выдает следующую ошибку:
{
"code": "ServiceProviderActionFailed",
"message": "The service provider action failed with error code 'ServiceOperationFailed' and error message 'The Service Bus session was not found to perform operation 'getMessagesFromQueueSession' on session id '30cb936a-4e11-4126-8047-4ac6f4b876b8'.'."
}
Я думаю, что причина ошибки заключается в том, что действие с учетом сеанса «Получить сообщения из сеанса очереди» можно использовать только в рабочем процессе, который запускается триггером с учетом сеанса, например «При одном новом сообщении из сеанса очереди». Однако в моем сценарии это невозможно. Мне нужно поддержать следующее:
http-клиент --запрос синхронизации--> диспетчер процессов приложения логики --> тема шины svc --> работник приложения логики --> очередь служебной шины --> диспетчер процессов приложения логики --синхронизация ответа --> клиент http
Я добавил изображение рабочего процесса RunBre, показывающее форму отправки сообщения, с правильным идентификатором сеанса.
Вам нужен идентификатор сеанса при получении сообщения, а также готовы ли вы не отправлять сообщение с идентификатором сеанса и не получать его?
Оказывается, то, что я пытался сделать, невозможно с помощью новых действий с учетом сеанса. Они будут работать только в рабочем процессе, который запускается одним из новых триггеров, поддерживающих сеанс - подробности здесь
В качестве обходного пути я добавил локальную функцию, которая использует пакет nuget Azure.Messaging.ServiceBus для чтения из очереди сеанса:
var client = new ServiceBusClient(serviceBusNamespace, credential);
var receiver = await client.AcceptSessionAsync(queueName, sessionId);
ServiceBusReceivedMessage message = await receiver.ReceiveMessageAsync();
Можете ли вы поделиться схемой конструкции RunBre?