Let's say, I have an enterprise application runs on Azure Web App Service. Among 100+ pages, I have 3-5 pages needs to be served real-time. to benefit from real-time capabilities of Azure SignalR Service, I want to make clients land on my SignalR application (which runs on RignalR Service). But I couldn't find any related example-article about it. How can I invoke a Hub method outside of the code? Any other approach to solve my problem is more than welcome. My main concern here is the performance of real-time pages.
If you have an ASP.NET Core SignalR Server (i.e. you have classes deriving from Hub in your application), you can't directly send messages to clients via the Azure SignalR Service. You'd have to provide an API in your ASP.NET Core application that does that.
Azure SignalR does also support a "serverless" mode in which you don't have a Hub on the server at all. In that model, clients connect directly to the service (instead of first connecting to your app) and then you can send messages to those clients using the REST API. This is a relatively new scenario so there isn't a lot of documentation. There are some blog posts and videos online on the subject, but not a lot of documentation.
If you already have an ASP.NET Core app, I'd suggest doing this by adding a REST API to your own application that allows other services in your application to send messages by calling this API. In the implementation of this API, you can use IHubContext<T> to send the messages.
Related
There is very limited information on azure signalR service. I need to clarify a question so any help would be highly appreciated.
how azure signalR service actually scale out ? I mean, as far I have worked on it. it seems that you have to include a primary key of azure signalR service to your hub. you can host you hub anywhere. So how hub scales out.?
SignalR Service manages all the client connections, as well as certain state information such as group membership. Your ASP.NET Core application establishes a connection to the SignalR Service instance.
When the application wants to send a message to connected clients, it uses this connection to instruct the service to do so. The service can also invoke hub methods via this connection.
You can read more about the service protocol.
When a client initiates a connection, it calls a negotiate endpoint on your ASP.NET Core application, which redirects the client to connect to the SignalR Service instance instead.
Because the ASP.NET Core application only needs to execute hub logic and most of the heavy lifting is done by SignalR Service, your application does not typically have to scale out to handle more SignalR connections. You can scale it based on the needs of the web traffic (serving web API and MVC requests, for example), and you can scale the service based on the needs of your SignalR traffic.
This is the documentation that I found and followed to have a signalr hub that worked across multiple App Service instances but behaving as a single hub.
You need to create a "backplane" in Azure using Storage queues and topics.
Details here: https://learn.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-with-windows-azure-service-bus
#anthonychu is this still needed / applicable??
I'm reading the very limited information about Azure SignalR service as well as the quick start guide and want to make sure I'm understanding this correctly.
We still seem to have a hub and if I understand this correctly, the function of Azure SignalR service is to simply push the messages to connected clients.
In my case, I store the history of chat so by hitting the hub first, I'm able to still use my backend logic to persist chat history or do any other processing that I may want. Then simply allow Azure SignalR service to push the data to connected clients.
The main benefit seems to be handling the scaling of the service.
Am I getting this right?
Yes, you are totally right.
You will use exactly the same API of ASP.NET Core SignalR to write your business logics, which means you can persist whatever you want when the messages from clients hit your hubs.
Azure SignalR Service will be the underlying transport between your app server and connected clients. For example, when you want to broadcast messages to all your clients, you actually only send one message to Azure SignalR Service and the service will broadcast the message to all clients for you. So that you don't have to worry about the scale-out. Azure SignalR Service will handle the scaling-out for you.
You understand correctly.
SignalR is not yet ready for production (when speaking about ASP.NET Core), SignalR for ASP.NET MVC has been around for a while (stable).
SignalR consists of 2 pieces: server and client. The server is as you describe: a "hub" that you can use to push information to clients.
On a webpage you load a piece of generated javascript (generated automatically from your hub definitions). Basically you let your website visitors (clients) connect to the hub through signalR's mechanism (signalR will choose the proper way to connect depending on the browser), and then 'subscribe' to the different methods you have active in your hub.
The workings are simple: whenever you call code in your hub (can be from clients, or from backend code) communication is automatically handled for you to all subscribed clients.
Note: If you are running this on an azure web app: enable the "always on" setting, and set the "websockets" toggle to "enabled", otherwise you'll see strange behaviour.
Note2: The RC version for signalR core 1.0 has just been released (7th of may 2018) so it might be a while before this software starts becoming stable and available through the public nuget/npm channels.
how to refresh local data automatically when server data changes in azure mobile app(android).Right now i m using a timer that refresh my server request but this approach is not satisfactory as my app keep on sending requests to azure.What is the best approach for doing this?I also tried to understand one of the answer in stack overflow based on Exponential Back Off Delay Based but failed to understand.Kindly just guide me on this
For communicating server-side updates to client apps, use SignalR.
Here's some guidance on using it with Azure Mobile Apps: Real-time with ASP.NET SignalR and Azure Mobile .NET Backend
We just released an update for Azure Mobile Services .NET backend which enables you to use ASP.NET SignalR for real-time, bi-directional communications with your mobile applications. SignalR will use WebSockets under the covers when it's available, and fallback to other “techniques” (i.e. HTTP hacks 😉) when it isn't. Regardless of the mode, your application code stays the same.
I have a service fabric cluster with a web API with signalR and a reliable actor setup.
I also have a separate MVC application that hits the web API.
I can connect to the signalR just fine with MVC app just fine and everything works well. But when I hit the API with the reliable actor which should then trigger a signalR broadcast to the group the MVC app is connected to, nothing comes across on my MVC app. I know it is hitting the API as I have it logging to be sure.
I have set the load balancer to Session persistence to Client IP. I am suspecting that the signalR hub might not be the same 'hub' or its on another node? Is there any way I can force it to all be on the same one so this communicates? Am I forgetting anything? Please let me know if I need to include more information.
The answer I found was SignalR Scaleout with Redis
Basically this uses redis to share signalR messages across all nodes in the service fabric.
Simply set up Redis, reference Microsoft.AspNet.SignalR.Redis and add this to your startup:
GlobalHost.DependencyResolver.UseRedis(new RedisScaleoutConfiguration(redisConnectionString, "SignalR"));
I have a Windows Azure Mobile Service up and running, however, there is a need for that service to consume some data expose through an external SOAP service and store that information in the mobile service database.
I would like to set up a worker in the mobile service, so the calls to the external SOAP service are executed in a fixed period of time.
I've been looking for a solution to this problem, but haven't found anything yet. So any help that would get me in the right direction would be appreciated.
Unfortunately there isn't an easy way to talk to a SOAP service from your Mobile Service backend. The backend is based on Node.js, and even though there are some Node modules for talking to SOAP services, they are currently not supported in Mobile Services. We are working on a solution that will enable you to use any Node module in your service, but it is not out yet.
If you control the SOAP service and it is written using WCF, you may be able to easily add a REST endpoint to the service with just a few config changes and then consume it from your Mobile Service via plain HTTP requests by using the "request" module.