how can I have two instances of the generic json handler?

[gregveres]

I originally thought I could do this by setting the Receiver variable to something that was application specific like: "inboundemail" rather than "genericjson", but it seems that the value of Receiver is what you guys use to determine the type of webhookHandler. Is that correct?

Is there a way to have two genericjson handlers? or is my genericjson handler just destined to get massive because it is going to have to handle every type of web hook request?

Thanks

[HenrikFrystykNielsen]

You can use the {id} part of the URI to separate out specific web hooks.

[gregveres]

which part is the {id} part?

if the url is /api/webhooks/incoming/genericjson/br

are you calling br the {id} part or genericjson?

I am already using quite a few different codes where br is in the URI. But that leads to one massive class for my single instance of GenericJsonWebHookHandler: WebHookHandler.

The ExecuteAsync method looks like a bunch of if statements like:

if (context.Id == "br") { // do some stuff to handle the br type } else if (context.Id == "otherId") { // do some other stuff }

Is that what you mean? I was hoping for a better design where I could create any number of classes that derive from WebHookHandler that all handle generic json data. So that I could have a:

BrWebHookHandler and an OtherIdWebHookHandler.

where the framework would differentiate which WebHookHandler to call based on replacing {genericjson} in the URI.

For instance, I have a bunch of different Ids all associated with incoming email reply handling. The different Ids are used based on the different types of emails we sent out. It helps the processing code to be small and focused. So I would love the URI that this lives off of to be:

/api/webhooks/incoming/emailreply/br

and then I would use my 5 or 6 different Ids (the br and otherId) to differentiate the email type.

But then I have another service that is sending me webhooks for member management. It is going to have its own set of operations that it wants to pass along to me. And it is also going to be generic json. I would like it to live off the URI:

/api/webhooks/incoming/members/update /api/webhooks/incoming/members/remove

But right now it seems like I have to put both of these into the same web hook handler and the path component after the incoming needs to be genericjson for the framework to find my web hook handler.

Am I missing something? Can I achieve what I am looking for and have multiple generic json handlers?

Thanks Greg

[mkArtakMSFT]

Hi. It looks like this is a question about how to use ASP.NET. While we do our best to look through all the issues filed here, to get a faster response we suggest posting your questions to StackOverflow.

[gregveres]

Sorry I don't see how this is a question on how to use ASP.NET. Doesn't the WebHooks project setup the routing rules automatically to handling things like the stripe handler or the genericjson handler or any of the other handlers?

If the webhooks project completely left the routing to the ASP.NET API 2.0 config, then I would agree with you. But to get the genericjson handler handling requests, I didn't touch my Api 2.0 config except to call the magic function: config.InitializeReceiveGenericJsonWebHooks();

You can tell me that the GenericJson handler doesn't support having multiple instances without handling the routing config myself. Is that what you are saying?

Or you can say that the design of the routing doesn't currently support multiple instances of the same type of handler without handling the routing config myself.

The documentation is fairly light so I am asking the question here. Thanks

[dougbu]

@gregveres please file future issues about ASP.NET WebHooks in the aspnet/AspNetWebHooks repo.

Since we haven't moved existing issues over there yet, I'll continue the conversation here…

which part is the {id} part?

Yes, br is the {id} in your example.

I was hoping for a better design where I could create any number of classes that derive from WebHookHandler that all handle generic json data.

Nothing prevents your idea. It's up to your handlers to decide what requests to handle. They set WebHookHandlerContext.Response to short-circuit other handlers. Or, they don't update the WebHookHandlerContext and other handlers get a chance.

E.g. you could take @HenrikFrystykNielsen's suggestion further and implement handlers for each {id} in your application:

    public class BrWebHookHandler : WebHookHandler
    {
        public GenericJsonWebHookHandler()
        {
            this.Receiver = GenericJsonWebHookReceiver.ReceiverName;
        }

        public override Task ExecuteAsync(string receiver, WebHookHandlerContext context)
        {
            if (context.Id != "br")
            {
                return Task.FromResult(false);
            }

            // Do br-specific stuff
            handlerContext.Response = {br-specific response or something generic to short-circuit handlers};

            Task.FromResult(false);
        }
    }

The OtherIdWebHookHandler class would look very similar but its context.Id check would look for otherId.

don't see how this is a question on how to use ASP.NET

@mkArtakMSFT meant the asp.net-webhooks tag in particular.

In a quick look, I didn't see an answer to these specific questions. But, StackOverflow members often have the answers at their fingertips.

[gregveres]

@dougbu

I just quickly read your response. I need to take a few minutes to digest it, which I don't have right now, but I very much appreciate you taking the time to answer.

I think I see what you are saying, the web hook processors are chained together and if one returns true, it means that the web hook handled it, don't pass it to the next in the chain. If I understand that correctly that makes sense and I see how I can achieve what I am after.

Thank you.

[dougbu]

Thank you for your feedback. We're closing this issue as the questions asked here have been answered.