Per al client de missatgeria Service Bus v7 de Node darrere d'un proxy HTTP, feu servir la disposició AMQP sobre WebSockets de l'exemple del 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 },
  },
});

Proporcioneu l'URL del proxy i la cadena de connexió de Service Bus. Per a una prova permesa d'un espai de noms públic de Service Bus sense autenticació del proxy, una entrada HTTP de la llista de proxies HTTP pot proporcionar proxyUrl. Els paquets ws i https-proxy-agent ja han de ser dependències de l'aplicació. La interfície subjacent d'agent proxy de ws manté el servei WebSocket i les adreces del proxy separats.

Això construeix el client; la connexió es produeix quan un remitent o destinatari duu a terme una operació. Manteniu-lo per a aquesta càrrega i espereu client.close() en tancar.

Localitzeu una fallada entre la configuració del túnel del proxy, la negociació de WebSocket i l'operació de Service Bus. El proxy ha de permetre aquesta destinació i sessió. Un accés HTTPS breu no demostra suport d'actualització ni un límit acceptable de connexions de llarga durada.

Aquesta és la sobrecàrrega amb cadena de connexió. Una credencial d'identitat pot afegir un camí d'obtenció de testimoni configurat per separat. Els fragments REST antics d'azure-sb fan servir una altra generació; identifiqueu el paquet abans de triar les seves opcions de transport.

Articles relacionats