Invocation Filters

[mathewc]

We should consider adding an Invoke Filter concept. This is very similar to WebAPI ActionFilters (the problem domain is basically the same). We've already had some related asks (see #734, #895). The idea is to provide a declarative programming model that allows people to attach filters to their job methods, classes, etc. similar to the way filters are specified in WebAPI. The invoke filter will receive a context object that contains everything needed to perform validations, do logging, etc. before any input/output bindings occur and before the function executes. In addition to invocation filters, we'll also enable different filter types mapping to different stages in the execution pipeline (e.g. exception/error filters). Here’s an sketch:

[ErrorHandler]
public static class Functions
{
    [ValidateOrder]
    public static void ProcessOrder([QueueTrigger(“orders”)] Order order) { … }
}

public class ValidateOrdeAttribute : InvokeFilterAttribute
{
    public override void OnExecuting(FunctionExecutingContext context) 
    {
        // perform validations, etc.
    }

    public override void OnExecuted(FunctionExecutedContext context) 
    {
        // perform validations, etc.
    }
}

This attribute could be applied at the function or class level. We could also support host level as well (e.g. add to JobHostConfiguration service collection). Just like WebAPI ActionFilters, where they can be specified declaratively, as well as at the service config level.

[abatishchev]

+1. Please. Otherwise extendability and traceability are actually very limited.

[jamesbascle]

I'd like to make a note that, IMO, this should support async WebJobs as first class citizens - it was actually a rather complicated and touchy thing to get working with my interception strategy. Having to add ContinuesWith, manually setting cancel/exception/result, and more, is a lot to ask when the entire point behind WebJobs is to keep things as simple as possible.

[mathewc]

@jamesbascle Of course we'd support async filters. Basically we'll be doing something like WebAPI ActionFilters. As you can see, that model supports sync/async. If you're asking for something more, please share details.

I realize my sketch code above didn't make that clear :)

[VenkateshSrini]

My two cents worth modification to your code

public static class Functions
{
    [MyInvokeFilter]
    public static void ProcessMessage([QueueTrigger(“test”)] string message) { … }
}

public class MyInvokeFilterAttribute : InvokeFilterAttribute
{
    public override Task OnExecuting(FunctionExecutingContext context) 
    {
        // perform validations, etc.
    }


    public override Task OnExecuted(FunctionExecutedContext context) 
    {
        // perform validations, etc.
    }
}

Can we also combine a sort of rules engine to these function context Out of the Box. This will actually provide the rules that needs be executed before the functions is executed. Otherwise it will exit without executing the rule. This is similar to rules of openWhisk. To start with we can leverage the WF4 rules engine.

Question how we will instantiate the rule engine in performance/cost efficient way. If we get this trick right then we are home

[dfaivre]

I assume like WebAPI, we could apply a filter globally?

[VenkateshSrini]

Applying only in function level right? Because each job in an isolated entity. Multiple jobs (dissimilar) could be packaged at runtime in a job host. So I think applying filter globally will not make that much sense

[jamesbascle]

It definitely makes sense, but it should be optional. They should be configurable via attributes on a per job function, per job class, and global basis.

…

On Mar 22, 2017 10:34 PM, "VenkateshSrini" ***@***.***> wrote: Applying only in function level right? Because each job in an isolated entity. Multiple jobs (dissimilar) could be packaged at runtime in a job host. So I think applying filter globally will not make that much sense — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#980 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD_ohWqZ1gNwaDTFIXkRTXCmyI5tBTQyks5rodpQgaJpZM4Lo0bI> .

[will-beta]

Looking forward to it!

[VenkateshSrini]

Is it closed because another PR has been opened or is it implemented. Please clarify

[jamesbascle]

@VenkateshSrini check the case and commits. It's merged into master dev.

[mathewc]

FYI - this feature is now available in the nightly builds on myget with version 2.1.0-beta1-10998. There is also a wiki page describing the feature here: https://github.com/Azure/azure-webjobs-sdk/wiki/Function-Filters

[sonic1981]

Despite this thread being from 2017 the link to that wiki still has

This features is still in preview. Please be cautious using this in production applications.

Is this true? Is it in preview or has it been accepted permanently now?

[sonic1981]

Looks like this is getting helb up by #1284

Specifically #1284 (comment)

[sonic1981]

Looking like this approach is going to get abandoned:

I can see some interest in this and so going to give the answer that may help folks plan the best, but things can always change. We don't have any plans to bring functions filters as currently implemented as this preview feature forward. That said, the scenario that many people are interested in using function filters for, namely to add some logic and middleware before an execution triggers, is something we do want to solve for. We have recently prototyped some features as part of the upcoming out of process .NET work that allows users to add some middleware to execute before a function triggers for something like token validation or whatnot. If you were to ask me today that's what I would say is the future of this scenario, and not function filters as implemented.

I'm happy to keep this issue open to continue discussion around it, but don't want folks to hold out thinking we are holding out and waiting to move this from preview to GA. There were always some tradeoffs with the approach we took with filters and we feel we may be able to provide the benefits in a more flexible way with something like middleware.

#1284 (comment)