Invocation Filters

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.

[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 😃

[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” [e-mail] 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 https://github.com/Azure/azure-webjobs-sdk/issues/980#issuecomment-288599850, or mute the thread https://github.com/notifications/unsubscribe-auth/AD_ohWqZ1gNwaDTFIXkRTXCmyI5tBTQyks5rodpQgaJpZM4Lo0bI .