Para el cliente de mensajería Service Bus v7 de Node detrás de un proxy HTTP, use la disposición AMQP sobre WebSockets del ejemplo 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 },
  },
});

Proporcione la URL del proxy y la cadena de conexión de Service Bus. Para una prueba permitida de un espacio de nombres público de Service Bus sin autenticación del proxy, una entrada HTTP de la lista de proxies HTTP puede proporcionar proxyUrl. Los paquetes ws y https-proxy-agent ya deben ser dependencias de la aplicación. La interfaz subyacente de agente proxy de ws mantiene separados el servicio WebSocket y las direcciones del proxy.

Esto construye el cliente; la conexión se produce cuando un remitente o receptor realiza una operación. Consérvelo para esa carga de trabajo y espere client.close() al cerrar.

Localice un fallo entre la configuración del túnel del proxy, la negociación de WebSocket y la operación de Service Bus. El proxy debe permitir ese destino y esa sesión. Un acceso HTTPS breve no demuestra compatibilidad con la actualización ni un límite aceptable de conexiones de larga duración.

Esta es la sobrecarga con cadena de conexión. Una credencial de identidad puede añadir una ruta de obtención de tokens configurada por separado. Los fragmentos REST antiguos de azure-sb usan otra generación; identifique el paquete antes de elegir sus opciones de transporte.

Artículos relacionados