הגדרות פרוקסי של טריגר Service Bus ב-Azure Functions בקובץ host.json

השתמשו ב-webProxy של host.json בהרחבת Service Bus 5.x עם amqpWebSockets, במקום להגדיר ServiceBusClient נוסף בקוד הפונקציה.

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

מזגו זאת לתצורת ה-host הקיימת של Functions. הרחבת הקישור יוצרת את הלקוח של הטריגר; לקוח שנבנה בנפרד בקוד הפונקציה אינו מחליף אותו.

הרחבה 5.x תומכת ב-webProxy עם amqpWebSockets, ולא ב-amqpTcp. השאירו namespace/authentication בהגדרת החיבור הקיימת של Service Bus. עבור namespace ציבורי של Service Bus שבו מתווכים ציבוריים מותרים, רשימת פרוקסי ה-HTTP מספקת מועמדים לכתובת webProxy ללא חשבון.

המקבילות בהגדרות האפליקציה הן:

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

השתמשו בהיררכיית הקו התחתון הכפול הזו בהגדרות הסביבה, או ברשומות בקובץ local.settings.json, בקטע Values, לפיתוח מקומי. אלו הגדרות host, לא שדות של מחרוזת חיבור.

התאימו לדור ההרחבה המותקן. לקוח HTTP או Service Bus עצמאי של worker מבודד עדיין זקוק למסלול משלו.

מאמרים קשורים