Pentru clientul de mesagerie Service Bus v7 al Node din spatele unui proxy HTTP, folosiți aranjamentul AMQP peste WebSockets din exemplul 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 },
  },
});

Furnizați URL-ul proxy-ului și șirul de conexiune Service Bus. Pentru un test permis al unui spațiu de nume public Service Bus fără autentificare proxy, o intrare HTTP din lista de proxy-uri HTTP poate furniza proxyUrl. Pachetele ws și https-proxy-agent trebuie să fie deja dependențe ale aplicației. Interfața subiacentă de agent proxy ws ține serviciul WebSocket și adresele proxy separate.

Aceasta construiește clientul; conectarea are loc când un expeditor sau destinatar efectuează o operație. Păstrați-l pentru acea sarcină și așteptați client.close() la oprire.

Localizați o defecțiune între configurarea tunelului proxy, negocierea WebSocket și operația Service Bus. Proxy-ul trebuie să permită acea destinație și sesiune. Accesul HTTPS scurt nu dovedește suport pentru upgrade sau o limită acceptabilă de conexiuni de lungă durată.

Aceasta este supraîncărcarea cu șir de conexiune. O acreditare de identitate poate adăuga o cale de obținere a tokenului configurată separat. Fragmentele REST azure-sb vechi folosesc altă generație; identificați pachetul înainte de a-i alege opțiunile de transport.

Articole similare