Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

Monitoring long operation progress via SignalR

, 26 Aug 2014 CPOL
Rate this:
Please Sign up or sign in to vote.
codeproject There are many cases when you want to start a long operation and watch its progress. In my Chpokk project (a C# and VB.Net IDE), you can see it when you create a project (primarily when adding NuGet packages, which can be long), compiling, executing, and automated testing. The proble

There are many cases when you want to start a long operation and watch its progress. In my Chpokk project (a C# and VB.Net IDE), you can see it when you create a project (primarily when adding NuGet packages, which can be long), compiling, executing, and automated testing. The problem is, we need to push the progress notifications from the server to the client, which is the opposite to what we are doing most of the time.

Let's use SignalR to make our life easier.

In most tutorials, SignalR is used to call the clients in response to some client's call. Like in a chat application, a client sends a message, the served broadcasts it to all clients.

Our case is different. We want a long running process to fire notifications. We could use the Hub class for that, but it is much more convenient to handle the original request (that started our process) via an Endpoint/Controller/whatever our main Web framework uses.

So, the Hub class is out, and we'll have to use the HubContext class.

Let's see the code.

To send a message to the client, we still need a Hub class, but it can be empty. We also need the ConnectionId value in order to send the message to the right client. The message itself can be sent in one line:

GlobalHost.ConnectionManager.GetHubContext<LogHub>()
                                  .Clients.Client(connectionId)
                                  .log(message);

Here "log(message)" is a method defined on the client (more on this later).

In order to make this work, we have to tell the server the value of connectionId. We can capture it at any time after the connection is established:

      var connectionId = $.connection.hub.id;

Later we send it to the server along with the data required for our long running process:

      $.post(url, {ConnectionId: connectionId, ...});

The $.post request starts the long running process on a separate thread and returns immediately.

Now that the server sends us messages, we need to handle them somehow (e.g. display them). Remember the log method we're calling on the server? We need to implement it on the client, which is standard for SignalR applications:

      $.connection.logHub.client.log = function(message){...};

We're done, let's celebrate!

While the implementation turned out to be very simple, I'm still happy that I forced myself to write this post (after being silent for about a year). I think logging a long running process is quite a common task for the apps that do something more interesting than CRUD, and having a post like this for a reminder is quite handy.

As always, you can get the sample code (a fully functional application) on GitHub. The actual code is a little bit different from what I write here, since I wanted it to be a bit structured. But the general idea is the same. Also, please check it in action in my online .Net code editor -- tell me what you think!

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Artem Smirnov
Software Developer GeekSoft
Lithuania Lithuania
No Biography provided
Follow on   Twitter

Comments and Discussions

 
GeneralMy vote of 5 PinprofessionalChristian Amado12-Sep-14 4:42 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.141220.1 | Last Updated 26 Aug 2014
Article Copyright 2014 by Artem Smirnov
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid