Azure Service Bus для Node.js: HTTP-проксі праз AMQP па-над WebSockets

Для кліента абмену паведамленнямі 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 не даказвае падтрымку абнаўлення або прымальны доўгатэрміновы ліміт злучэнняў.

Гэта перагрузка з радком злучэння. Уліковыя даныя ідэнтычнасці могуць дадаць асобна наладжаны шлях атрымання токена. Старыя фрагменты azure-sb REST выкарыстоўваюць іншае пакаленне; вызначце пакет, перш чым выбіраць яго параметры транспарту.