[FEATURE REQ] [Microsoft.Azure.WebJobs.Extensions.EventHubs] Custom Endpoint support feature falls short when using AMQP and more than one event hub per Azure Function App

[cmendible]

trafficstars

Library name

Microsoft.Azure.WebJobs.Extensions.EventHubs

Please describe the feature.

The current implementation of Custom Endpoint allows its value to be set only once in the host.json file.

This limitation becomes problematic when attempting to connect to multiple Event Hub Namespaces from a single Azure Function App.

For example, if using an application gateway in front of your Event Hubs, you’ll need to add a listener for each Event Hub Namespace you want to support via AMQPS. Consequently, if you have an Azure Function with a trigger from one namespace and a binding to another, there is no way to configure it correctly.

We should be able to set the custom endpoint in the triggers and bindings, or in a map inside the host.json file.

[github-actions[bot]]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jsquire]

Hi @cmendible. Thanks for reaching out and we regret that you’re experiencing difficulties. This is a regrettable limitation of the way that Functions manages configuration. In order to support a per-trigger setting, they must be pulled up into the trigger attribute. This forces a trade-off between complexity and customization. The trigger attribute already receives feedback that it is confusing, so we’re very conservative in adding new properties to it.

The custom endpoint address is a niche feature not widely used by developers. Unless we see active demand for your scenario, I don’t see this as something that would justify the additional trigger complexity. We’ll leave this open for a bit to watch for additional requests.

In the meantime, the work-around is to use a single Event Hub per Function app when configuring the custom endpoint address.

[jsquire]

To enable this support, we would have to add a parameter to the trigger attribute that shadows the host.json configuration, which adds both confusion and complexity for developers. Given the low use of custom endpoint address, the limited scenarios for its use, the lack of customer requests to add at the Function level, we're not going to move forward with this request at the present time.