1

I have a ASP.Net Web Api application that updates some entities in a database using Entity Framework. When certain ones are updated I plan to publish the updated to an Azure Service Bus queue which is then picked up and handled by other systems.

I'm not too sure how to kick off the process of adding the message to the queue from the Web Api. I know I can't do too much after I have returned a response in the api so wasn't sure whether to run the code then, or possibly raise an event. But then I don't want to have a message queue to add messages to the main queue.

I don't want this to impact the response time to the user so do want to do it asynchronously. Any ideas?

ADringer
  • 2,614
  • 36
  • 63
  • I am not familiar with Azure Service Bus but any ESB solution should be able to handle asynchronous events. Maybe this could be a solution to your problem: http://stackoverflow.com/questions/15612407/azure-servicebus-async-to-be-or-not-to-be#15614417 – Vyrira Oct 26 '16 at 21:34
  • @Vyrira Thanks, but I've got the code to add the message to the queue. I'm wondering what's the best way to invoke the code from a web api if I don't want it to impact response time. – ADringer Oct 27 '16 at 07:17
  • The simplest way would be to put the code that sends the message inside `Task.Run(() => {});` and not await it. Or if you´re code already returns a task, dont await it. Note though that this is not the best solution http://blog.stephencleary.com/2014/06/fire-and-forget-on-asp-net.html – peco Oct 27 '16 at 12:41

1 Answers1

0

Microsoft has some great links about design patterns and reference architectures in the Azure Center.

If you don't want to affect the user's response, I would dump the message to a service-internal queue, and send those messages to the service bus on a separate worker. If message delivery is imperative, then this is probably a good strategy to use, because you can save the data and re-visit it if necessary.

I know you said you don't want to affect response time, but do want to deliver the messages as part of the HTTP Controller Action. Here are some considerations:

  1. Where is your API being installed with respect to the Azure queue? Are both in Azure? Are the services co-located?
  2. Does the caller need to be notified if delivery to the Azure Service Bus fails?
  3. Are you performing any other processing inside the controller that is dependent on the outcome of posting to the service bus?
  4. Should re-tries be supported?

If #1 is anything resembling "yes," then I would suggest that you can just wrap the action of posting to the service bus inside a Task, and determining your own result based on the outcome of that task (and whatever other processing you're performing). If there are multiple scenarios, and #1 is yes, then you can also consider having two modules that implement a common interface, but essentially using a strategy pattern for different (installation) scenarios.

If you aren't co-located, or expect to be anything other than co-located with Azure at any point, it is worth considering using a local queue to publish messages to, and spawning some kind of a worker to handle messages on that queue. You may find this provides the best trade-off of user experience and reliability.

Hope this helps.

PSGuy
  • 653
  • 6
  • 17