עבור לקוח ההודעות Service Bus v7 של Node מאחורי פרוקסי HTTP, השתמש בסידור AMQP-over-WebSockets מדוגמת ה-SDK:

const { ServiceBusClient } = require("@azure/service-bus");
const WebSocket = require("ws");
const { HttpsProxyAgent } = require("https-proxy-agent");

const proxyAgent = new HttpsProxyAgent(proxyUrl);
const client = new ServiceBusClient(connectionString, {
  webSocketOptions: {
    webSocket: WebSocket,
    webSocketConstructorOptions: { agent: proxyAgent },
  },
});

ספק את כתובת ה-URL של הפרוקסי ואת מחרוזת החיבור של Service Bus. לבדיקה מורשית של מרחב שמות ציבורי של Service Bus ללא אימות פרוקסי, רשומת HTTP מרשימת פרוקסי ה-HTTP יכולה לספק proxyUrl. החבילות ws ו-https-proxy-agent חייבות כבר להיות תלויות של היישום. ממשק סוכן הפרוקסי הבסיסי של ws שומר על שירות ה-WebSocket וכתובות הפרוקסי בנפרד.

זה בונה את הלקוח; החיבור מתרחש כאשר שולח או מקבל מבצע פעולה. שמור אותו לעומס העבודה הזה והמתן ל-client.close() בעת הכיבוי.

אתר כשל בין הקמת מנהרת הפרוקסי, משא ומתן WebSocket ופעולת Service Bus. הפרוקסי חייב להתיר את היעד והסשן האלה. גישה קצרה ב-HTTPS אינה מוכיחה תמיכה בשדרוג או מגבלת חיבורים ארוכי טווח מקובלת.

זוהי העומס עם מחרוזת חיבור. אישור זהות יכול להוסיף מסלול נפרד להשגת אסימון. קטעי azure-sb REST ישנים משתמשים בדור אחר; זהה את החבילה לפני בחירת אפשרויות התעבורה שלה.

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