Для клієнта обміну повідомленнями Service Bus v7 у Node за HTTP-проксі використовуйте схему AMQP поверх 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 не доводить підтримку оновлення чи прийнятний ліміт довготривалих з'єднань.

Це перевантаження з рядком підключення. Облікові дані ідентичності можуть додати окремо налаштований шлях отримання токена. Старі фрагменти REST для azure-sb використовують інше покоління; визначте пакет, перш ніж вибирати його транспортні параметри.

Схожі статті