C# web service do something after return response

Question

I have a web service called S

My client have a web service called C

My client send a request to my web service (web service S)
Web service S will send a response to client ( C )
After that, my service (S) will create 1 invoice message and send it to client web service (C)
Client web service return result to my web service (S)

How to implement it?

Thank for reply @Nkosi . but the requirement is that it will implemented by web service I personally think signalR difference with this — minhhungit, Jun 25 '16 at 22:37
Your own webservice, at #2, could call your #4 endpoint in a fire-and-forget way (you call your webservice and do not wait for a response). This will free the caller method to continue, sending the response in #3. Does it make sense? — Andre Calil, Jun 25 '16 at 23:45
I upvoted just to neutralize the downvote. When someone downvotes the question and every answer without comment it gives the impression that they're just bored. If they're not going to add anything to the discussion then why not just leave it alone? — Scott Hannen, Jun 26 '16 at 01:01
@Andre Calil: problem is I want to create invoice request **after** step 3. It looks I should use something like callback or async — minhhungit, Jun 26 '16 at 01:09
When part of this process happens on one web service and another happens in a different web service then it helps to think of them independently. Assume that neither application is aware of steps performed by the other. Each step performed within an application should be independent of other steps performed within that same application. They might combine to form a logical process, but from a programming perspective each should be as separate from the others as possible. — Scott Hannen, Jun 26 '16 at 01:15

score 2 · Accepted Answer · edited May 23 '17 at 12:32

As I understand, you want to return a response to client app, but still continue with some processing. There are a few possibilities here:

Start a new thread in 2., that will create the invoice and send it to client WS. This however can be error-prone - your web service might die or be shut down in the middle of creating the invoice and client WS will never know.
Use something like hangfire to schedule invoice creation. Hangfire stores scheduled tasks in DB, so it will be eventually executed, even in case of failure. This does not require additional configuration other than setting up the backend db. Processing happens in the same hosting process of your Service.
Use a ServiceBus or MSMQ - the idea is simmilar as with Hangfire - you send a message (saying like "create invoice with parameters X") to the Bus, the Bus makes sure the message gets delivered to anyone that listens for it. Then you register a listener that would handle that kind of message and create the invoice. This would require more work, since you have to choose the Service Bus engine, take a moment to understand it, install, configure, etc.

I need to catch response from step 6, so I can't use **fire-and-forget** method. Anyway, "stores scheduled tasks in DB" is also a good solution — minhhungit, Jun 26 '16 at 01:11
That's entirely possible - you fire a piece of code that will do all the steps fro 4 to 7. — qbik, Jun 26 '16 at 06:13

Scott Hannen · Answer 2 · 2016-06-26T00:48:15.050

This is a good case for a domain event. I don't know what the first request is - perhaps placing an order? When the order is placed then you would raise an event indicating that an order was placed. The event could contain either some information about the order or a reference (id) that can be used to retrieve it. Then other listeners would respond accordingly.

One benefit is that it keeps different parts of your application decoupled. For example, the class that submits an order doesn't need to know that there's going to be an invoice. It just raises an event indicating that an order has been placed and then goes on its way.

That becomes even more important if you want to have multiple behaviors when an order is placed. Perhaps you also want to send an email confirming that your received the order. Now you can add that additional behavior as an event listener with no modification to the code that places the order.

Also, your application could grow so that perhaps there's another service for placing orders. (I'm running with "placing orders" although I don't know what the specific event is.) You don't want multiple points in your application that follow all of the post-ordering steps. If those steps change then you'd have to modify code in all of those places. Instead you just raise the event.

Here's a popular article that describes the concept well. There are numerous implementations of an event bus. Here's one.

In pseudocode, you could now have a few event handlers, each of which is completely decoupled from your ordering code.

The event itself is raised immediately after the order is submitted.

var order = SubmitOrder(info); 
eventBus.Raise(new OrderSubmitEvent(order));

Then you have some event handlers which are registered to respond to that event.

public class SendInvoiceOrderEventHandler : IEventHandler<OrderSubmitEVent>
{
    public void HandleEvent(OrderSubmitEvent e)
    {
        //e contains details about the order. Send an invoice request
    }
}

public class SendConfirmationOrderEventHandler : IEventHandler<OrderSubmitEVent>
{
    public void HandleEvent(OrderSubmitEvent e)
    {
        //send an email confirmation
    }
}

@ scott: I'm still reading your comment. It sounds complicated — minhhungit, Jun 26 '16 at 01:29
I need to make sure that step 3 is done before step 4, can it do ? — minhhungit, Jun 26 '16 at 02:06
Event is raised before we send response. I need eventBus.Raise(new OrderSubmitEvent(order)); run after "return" statement — minhhungit, Jun 26 '16 at 02:21
You can't - when you call `return` the method stops executing. You can raise the event (or do anything else) before calling `return`. If it's a long-running process then you could execute it on another thread. You're right - you asked one question and I answered with two concepts - domain events and dependency injection. In general, dependency injection is much more useful to learn. If you learn that then it leads naturally to other beneficial patterns. — Scott Hannen, Jun 26 '16 at 04:00

C# web service do something after return response

2 Answers2