Налады проксі для трыгера Service Bus у Azure Functions у host.json

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "transportType": "amqpWebSockets",
      "webProxy": "http://proxy.example:8080"
    }
  }
}

Дадайце гэта ў існуючую канфігурацыю хоста Functions. Пашырэнне прывязкі стварае кліент трыгера; асобна створаны кліент у кодзе функцыі яго не замяняе.

Пашырэнне 5.x падтрымлівае webProxy з amqpWebSockets, а не amqpTcp. Пакіньце прастору імёнаў/аўтэнтыфікацыю ў існуючай наладзе злучэння Service Bus. Для публічнай прасторы імёнаў Service Bus, дзе дазволены публічныя пасрэднікі, спіс HTTP-проксі прапануе варыянты для URL webProxy без уліковага запісу.

Эквіваленты ў наладах праграмы:

AzureFunctionsJobHost__extensions__serviceBus__transportType=amqpWebSockets
AzureFunctionsJobHost__extensions__serviceBus__webProxy=http://proxy.example:8080

Выкарыстоўвайце гэтую іерархію з падвойнымі падкрэсленнямі ў наладах асяроддзя або запісы ў файле local.settings.json, раздзел Values, для лакальнай распрацоўкі. Гэта налады хоста, а не палі злучэння.

Адаптуйце пад усталяванае пакаленне пашырэння. Незалежны HTTP- або Service Bus-кліент ізаляванага worker усё роўна мае патрэбу ў сваім маршруце.