Setări de proxy pentru triggerul Service Bus din Azure Functions în host.json

Folosiți webProxy din host.json al extensiei Service Bus 5.x cu amqpWebSockets, în loc să configurați alt ServiceBusClient în codul funcției.

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

Îmbinați aceasta în configurația existentă a gazdei Functions. Extensia de legare creează clientul triggerului; un client construit separat în codul funcției nu îl înlocuiește.

Extensia 5.x acceptă webProxy cu amqpWebSockets, nu amqpTcp. Păstrați namespace/autentificarea în setarea de conexiune Service Bus existentă. Pentru un namespace Service Bus public unde sunt permise intermediari publici, lista de proxy HTTP oferă candidați pentru URL-ul webProxy fără cont.

Echivalentele din setările aplicației sunt:

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

Folosiți acea ierarhie cu dublu underscore în setările de mediu, sau intrări în fișierul local.settings.json, secțiunea Values, pentru dezvoltare locală. Sunt setări de gazdă, nu câmpuri de connection string.

Aliniați-vă la generația de extensie instalată. Clientul HTTP sau Service Bus independent al unui worker izolat are în continuare nevoie de propria rută.

Articole similare