For SignalR, the example is always a chat application. I wanted to take a different route and provide an example of a real-time scenario as following.
- When a customer places an order the admin will receive a notification
- When the Admin accepts/rejects the order the customer will receive notification.
As the real time collaboration increases we are often in a situation to provide updates to the applications and then an event occurs. In order to provide real-time updates or push contents to the consumers from the server, we use the SignalR library provided by Microsoft. In simple words, when we want to push some contents from server to the client application (ex: web app) we use signalR.
Let me explain using the demo project I have created then the things would be clear.
The following Azure services are used,
- Service bus queue – to de-couple Admin and customer end
- Azure functions with SignalR – to push real time notifications.
- Azure function Service Bus bindings – to process the messages.
- Azure SignalR
Below is the project structure,
Azure Functions
Process Order - Service bus binding to process the incoming messages when an order is placed by the customer and also passes a message “order Placed” to the SignalR which will be pushed to the admin web app.
SignalRNegotiate
This negotiate function is required by Azure signalR service where clients do the handshake and get the connection details of signalR. This is the communication point between two ends of SignalR publisher and subscriber.
UpdateOrderStatus
This function will be called when Admin accepts/reject the order status and put the respective message to the SignalR and then pushed to the customer.
The above 3 functions require Azure SignalR connection string. Azure SignalR can be created from the Azure portal.
Let’s dive a bit into the application.
In the Customer application HomeController - > Place Order method, the details of the order have been placed into the service bus queue, which will trigger the Azure function “ProcessOrder”. The “ProcessOrder” Azure function saves the details to the DB and places a message in the SignalR notification hub with the specific target name. In our example, it is “productordered”. Whoever listens to this SignalR target will be notified and the data will be shared.
- using (var ctx = new EventMessagingDemoContext())
- {
- ctx.Orders.Add(order);
- ctx.SaveChanges();
- }
- signalRMessages.AddAsync(
- new SignalRMessage
- {
- Target = "productOrdered",
- Arguments = new[] { order }
- });
- }
At the admin end, the SignalR service is connected via JavaScript. The withURl() function specifies the “negotiate” Azure function. Through this, it receives the SignalR connection and waiting for messages on the “productordered’ target. Once received, the alert will be shown with the message.
- var connection = new signalR.HubConnectionBuilder()
- .withUrl("http://localhost:7074/api/")
- .configureLogging(signalR.LogLevel.Information)
- .build();
-
- connection.start().then(function () {
- console.log("connected");
- });
-
- connection.on('productOrdered', function (order) {
- alert("order recieved for the product " + order.ProductName + ".Please refresh!");
- });
The same way the accept/reject message is communicated to the customer via SignalR.
The source code can be found
here.
Conclusion
With the above sample, we could get a basic idea and understanding of how SignalR works and the purpose of it.