Azure Service Bus för Node.js: HTTP-proxy via AMQP över WebSockets

För Nodes Service Bus v7-meddelandeklient bakom en HTTP-proxy, använd SDK-exemplets AMQP-over-WebSockets-uppsättning:

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 },
  },
});

Ange proxy-URL:en och Service Bus-anslutningssträngen. För ett tillåtet test av ett offentligt Service Bus-namnområde utan proxyautentisering kan en HTTP-post från HTTP-proxylistan ge proxyUrl. Paketen ws och https-proxy-agent måste redan vara applikationsberoenden. Det underliggande ws-proxyagentgränssnittet håller WebSocket-tjänsten och proxyadresserna åtskilda.

Detta bygger klienten; anslutning sker när en avsändare eller mottagare utför en åtgärd. Behåll den för den arbetsbelastningen och vänta på client.close() vid avstängning.

Hitta ett fel bland proxy-tunnelns uppsättning, WebSocket-förhandlingen och Service Bus-åtgärden. Proxyn måste tillåta den destinationen och sessionen. Kort HTTPS-åtkomst bevisar inte stöd för uppgradering eller en acceptabel gräns för långvariga anslutningar.

Detta är överlagringen med anslutningssträng. En identitetsuppgift kan lägga till en separat konfigurerad väg för tokenhämtning. Gamla azure-sb REST-utdrag använder en annan generation; identifiera paketet innan du väljer dess transportalternativ.