'Azure Function With ServicueBusTrigger Behind Proxy Not working
From title It is evident that I have some issue related to proxy.
- If I disable the proxy or machine without proxy, everything seems to be working fine.
- When proxy and vpn enable at that time if I try to publish message or receive message via servicebustrigger in azure function not working.
- To the some extends for publish that issue can be resolved by creating ServiceBusClient and configuring the proxy for that.
- For ServiceBusTrigger there is no option to configure proxy setting or atleast I am not aware of that.
Any suggestion ?
Solution 1:[1]
The Microsoft.Azure.WebJobs.Extensions.ServiceBus extension used by the ServiceBusTrigger uses the AzureFunctionsJobHost:extensions:ServiceBus config section to build the Service Bus client used by the input binding: ServiceBusHostBuilderExtensions.cs:44
You can therefore, configure the client to use the proxy by setting the "AzureFunctionsJobHost:extensions:ServiceBus:WebProxy" property in your local.settings.json file (or any other way you set your configuration):
"AzureFunctionsJobHost:extensions:ServiceBus:WebProxy": "<proxy address and port>",
Additionally, if your proxy does not allow you to use the AMPQS port (5671), you can configure the Service Bus client to use AMQP over Web Sockets (which uses port 443) by setting the AzureFunctionsJobHost:extensions:ServiceBus:TransportType property to AmqpWebSockets.
"AzureFunctionsJobHost:extensions:ServiceBus:TransportType": "AmqpWebSockets"
The environment used to test this:
- Framework: .NET 6 (in-process)
- Azure Functions Version: v4
- Microsoft.NET.Sdk.Function: 4.0.1
- Microsoft.Azure.WebJobs.Extensions.ServiceBus: 5.2.0
Solution 2:[2]
NServiceBus with Azure Functions is configured via ServiceBusTriggeredEndpointConfiguration which has a Transport property of AzureServiceBusTransport type. Using the Transport property, you should be able to specify the connectivity by enabling WebSockets.
Solution 3:[3]
This isn't a complete answer, but adding ;TransportType=AmqpWebSockets to the connection string should in theory cause the trigger to use web sockets. I am still investigating this myself - I have found that it can now peek successfully, but is failing to complete the read at the end.
I am configuring the proxy in the startup (using [assembly: FunctionsStartup(typeof(Startup))] and a class derived from FunctionsStartup - see "Microsoft.Azure.Functions.Extensions".
Solution 4:[4]
I used following startup class to set Amqp Web Socket transport and make it working for me when working locally behind the proxy.
using AzureFunctions;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Hosting;
using Microsoft.Extensions.Hosting;
using System;
[assembly: WebJobsStartup(typeof(Startup))]
namespace AzureFunctions
{
public class Startup : IWebJobsStartup
{
public void Configure(IWebJobsBuilder builder)
{
if (IsLocalDevelopmentEnvironment)
{
builder.AddServiceBus(options =>
{
options.TransportType = Azure.Messaging.ServiceBus.ServiceBusTransportType.AmqpWebSockets;
});
}
}
private bool IsLocalDevelopmentEnvironment => Environment.GetEnvironmentVariable("AZURE_FUNCTIONS_ENVIRONMENT") == "Development";
}
}
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Maciej Porebski |
| Solution 2 | Sean Feldman |
| Solution 3 | open-collar |
| Solution 4 | Maciej Gudanowicz |
