Azure Service Bus Node.js-ისთვის: HTTP პროქსი AMQP-ით WebSockets-ზე

HTTP პროქსის უკან მყოფი Node-ის Service Bus v7 შეტყობინებების კლიენტისთვის გამოიყენეთ SDK-ის ნიმუშის AMQP-over-WebSockets განლაგება:

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

მიაწოდეთ პროქსის URL და Service Bus-ის კავშირის სტრიქონი. პროქსის ავთენტიფიკაციის გარეშე დაშვებული საჯარო Service Bus namespace-ის ტესტისთვის HTTP პროქსების სიიდან HTTP ჩანაწერს შეუძლია proxyUrl-ის მოწოდება. ws და https-proxy-agent პაკეტები უკვე უნდა იყოს აპლიკაციის დამოკიდებულებები. ძირითადი ws პროქსი-აგენტის ინტერფეისი WebSocket სერვისსა და პროქსის მისამართებს ცალ-ცალკე ინახავს.

ეს ქმნის კლიენტს; კავშირი ხდება მაშინ, როცა გამომგზავნი ან მიმღები ოპერაციას ასრულებს. შეინარჩუნეთ იგი ამ დატვირთვისთვის და გამორთვისას დაელოდეთ client.close()-ს.

იპოვეთ ხარვეზი პროქსის გვირაბის დაყენებას, WebSocket-ის მოლაპარაკებასა და Service Bus-ის ოპერაციას შორის. პროქსმა უნდა დაუშვას ეს დანიშნულება და სესია. მოკლე HTTPS წვდომა არ ამტკიცებს განახლების მხარდაჭერას ან გრძელვადიანი კავშირების მისაღებ ლიმიტს.

ეს არის კავშირის სტრიქონის გადატვირთვა. იდენტობის სერტიფიკატს შეუძლია დაუმატოს ცალკე კონფიგურირებული ტოკენის მიღების გზა. ძველი azure-sb REST ფრაგმენტები სხვა თაობას იყენებენ; იდენტიფიცირეთ პაკეტი მისი ტრანსპორტის პარამეტრების არჩევამდე.