Очередь триггера служебной шины Azure не попадает в код при локальной отладке

Создана функция Azure с триггером служебной шины и развернута на портале Azure. Используя servicebusexplorer, отправляю очередь на портал и работаю нормально. Но после того, как остановил функцию в лазурном, отправив сообщение из проводника в локальный код в Visual Studio для отладки. Но он не срабатывает.
Я указал строку подключения службы в local.settings.json, и имя очереди верное. Он выдает ошибку в лазурном CLI после запуска функции из Visual Studio.

ОШИБКА:

Ошибка MessageReceiver (Action = Receive, ClientId = MessageReq.queue, Endpoint = sss-bbbb.servicebus.windows.net) xxxxx.queue, EntityPath = sss.ccccc
Microsoft.Azure.ServiceBus: попытка подключения не удалась из-за подключенного сторона не ответила должным образом по прошествии определенного периода времени, или установление соединения не удалось из-за того, что подключенный хост не смог ответить ErrorCode: TimedOut. System.Private.CoreLib: попытка подключения не удалась, потому что подключенная сторона не ответила должным образом по прошествии определенного периода времени, или установление соединения не удалось из-за того, что подключенный хост не ответил.

local.settings.json

   {    
        "IsEncrypted": false,    
      "Values":     
     {     
          "AzureWebJobsStorage": "UseDevelopmentStorage=true",     
          "AzureWebJobsDashboard": "UseDevelopmentStorage=true",    
          "FUNCTIONS_WORKER_RUNTIME": "dotnet",     
          "ServiceBusConnectionString": "Endpoint=//",    
          "RequestTimeout": "600000"    
      }

azureservicebus azure-functions azure-servicebus-queues visual-studio-2017 service-bus-explorer
person sam    schedule 13.09.2019    source источник
comment
у вас есть настоящая конечная точка в вашей конфигурации, верно? это не совсем ServiceBusConnectionString: Endpoint = //,   -  person Twisted    schedule 14.01.2020

Ответы (2)


arrow_upward
6
arrow_downward

У меня была аналогичная проблема с корпоративными брандмауэрами, блокирующими трафик служебной шины. Я добавил TransportType=AmqpWebSockets в конец строки подключения, и это сработало.

person Ian Bennett    schedule 26.11.2019
comment
Спасибо! Я мог бы исправить мою локальную среду с помощью этого исправления. - person Anderson Rancan; 18.02.2020

arrow_upward
0
arrow_downward

Я уже видел подобное раньше, когда политики локального брандмауэра блокировали соединения AMQP, которые используются функциями. Консольное приложение, скорее всего, также не смогло бы использовать пакеты SDK .NET Core служебной шины, если бы это было так. Тем не менее, не могли бы вы попробовать в другой сети? Ошибка означает, что это проблема разрешения сети.

person jeffhollan    schedule 14.09.2019