Azure Service Bus pour Node.js : proxy HTTP via AMQP sur WebSockets

Pour le client de messagerie Service Bus v7 de Node derrière un proxy HTTP, utilisez la disposition AMQP sur WebSockets de l'exemple du 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 },
  },
});

Fournissez l'URL du proxy et la chaîne de connexion Service Bus. Pour un test autorisé d'un espace de noms Service Bus public sans authentification proxy, une entrée HTTP de la liste de proxys HTTP peut fournir proxyUrl. Les paquets ws et https-proxy-agent doivent déjà être des dépendances de l'application. L'interface sous-jacente d'agent proxy de ws garde le service WebSocket et les adresses du proxy séparés.

Ceci construit le client ; la connexion se produit lorsqu'un expéditeur ou un récepteur effectue une opération. Conservez-le pour cette charge de travail et attendez client.close() à l'arrêt.

Localisez une défaillance parmi la configuration du tunnel proxy, la négociation WebSocket et l'opération Service Bus. Le proxy doit autoriser cette destination et cette session. Un accès HTTPS court ne prouve ni la prise en charge de la mise à niveau ni une limite acceptable de connexions de longue durée.

Il s'agit de la surcharge avec chaîne de connexion. Un justificatif d'identité peut ajouter un chemin d'obtention de jeton configuré séparément. Les anciens extraits REST azure-sb utilisent une autre génération ; identifiez le paquet avant de choisir ses options de transport.