azure-functions-host: Support for not so custom TriggerBinding

@paulbatum So you agree the change is good, but the team has no time. Is there a way community could contribute to this? I guess NServiceBus guys and other geeks like me 😃 could spend their time on features that they find valuable. Embrace the open source, you know.

Obviously some effort from the team would still be required. But isn’t that the higher priority work then - helping others to help you?

One obvious problem is lack of scale controller open code, but I’m not sure how many changes are needed there.

OK I spent a bunch of time playing with this. The TL;DR is that in general, you can use the extensions model to add additional types that user code can bind to, without having to implement a custom trigger itself. The example I used was a wrapping type for EventData (from the event hubs extension). The extension is just:

    public class MyEventHubExtension : IExtensionConfigProvider
    {
        public void Initialize(ExtensionConfigContext context)
        {
            context.AddConverter<EventData, MyEventData>(x => new MyEventData { InnerEventData = x });
        }
    }

    public class MyEventData
    {
        public EventData InnerEventData { get; set; }

        public string GetAsUTF8String()
        {
            return Encoding.UTF8.GetString(InnerEventData.Body.ToArray());
        }
    }

I was able to write and execute an event hub triggered function that used this extension:

    public static class EventHubProcessor
    {
        [FunctionName("EventHubProcessor")]
        public static void Run([EventHubTrigger("extensiontesthub", Connection = "EventHubConnection", ConsumerGroup = "functions")] MyEventData myData, TraceWriter log)
        {
            log.Info($"C# Event Hub trigger function processed a message: {myData.GetAsUTF8String()}");
        }
    }

However, Tomasz is correct with his observations about the queue trigger. It seems like it doesn’t participate correctly in the extensibility model so if you tried to do the same as above but for a queue triggered function it would not work. I have filed this issue to track: https://github.com/Azure/azure-webjobs-sdk/issues/1696

I think it makes sense to leave this issue open, because not ALL scenarios can be handled with a custom converter. You might want to change the retry or error semantics for a given trigger type while still relying on the standard scale controller monitoring behavior for activation and scale out. But for all the scenarios where you just want to add the ability to use a new type from the function code, I would suggest using the approach outlined above (which would be viable for queue triggers if that 1696 issue is resolved).

@paulbatum first of all thank you for your insights and comments.

Let me try sharing context from my end.

But in the scheme of things, we’re going to lean towards prioritizing features or fixes that unblock scenarios that simply aren’t possible, rather than the ones that save a few lines of code. Let me know if I’m miss characterizing this scenario.

As mentioned in the issue description custom trigger is a solution to a set of problems that I was trying to tackle. Let me try describe them in more detail in context of asq trigger:

• It not support serialization customization - what it means is that any sender has to comply to the serialization format. This is far from perfect especially in scenarios were existing system is extended with new features build on top for Azure Functions. Even if the sender is using Json it can still be incompatible e.g. because of BOM,
• It does not support extending binding data collections based on message content - what it means is that in scenarios when message content contains both control (e.g. headers) data and business data there is not easy way to separate the two,

In general those overlap with scenario mentioned by @mikhailshilkov in which it’s hard to provide a business level function signature (business data as input types) and float control data behind the scenes.

To clarify - my reply was to Mikhail, just saw your post Tomasz, thanks for the info.

@paulbatum I would not necessarily categorize custom bindings/triggeres as a few lines of code saved for users. Take for example @tmasternak 's original question. He’d like to enable NServiceBus customers to use Functions. It is more than just a few lines of code.

Another example (ironically, asked by an internal MSFT team) is to use Functions with Azure Service Bus to support messages larget than 1 MB to migrate from MSMQ. There’s a plugin for ASB seamlessly implementing claim check pattern. The existing Service Bus trigger doesn’t support plugins registration. That would mean duplicating what plugin is doing in all of their functions and owning that implementation rather than focusing on core busines requirement.

I understand the desire to focus on the lower hanging fruits. At the same time, would not understimate the ability to create custom triggers that are first class citizens when it comes to scale, rather than just nice demos for blog posts 🙂