Azure serverless signalR - if Receiver is not available - signalr

I am using Azure serverless signalR with Azure functions to broadcast messages to the single and multiple users. I have a question, if receiver is not connected to signalR,
1) Is Azure signalR helps in storing those messages and redeliver when receiver is available..??
2) I am using the UserId during negotiation with the azure function signalR , while message sending can it be possible to see who are connected to Azure serverless signalR in azure function.
could anyone please help in answer above questions.
Thanks

Is Azure signalR helps in storing those messages and redeliver when receiver is available..??
This is not possible and by design for SignalR Service. This is stated in the docs as well.
You would have to implement this separately.
I am using the UserId during negotiation with the azure function signalR , while message sending can it be possible to see who are connected to Azure serverless signalR in azure function.
While the Azure SignalR Service maps users and connections internally, there is no way to query this information. But the service raises events which you can use to create your own mapping that you can use in your application.

Related

Pub-Sub model for interacting between Web API applications

We have an application which has set of APIs developed in .NET CORE and UI which consume these APIs developed in Angular(both are independent projects) . Both are hosted on azure app service.
WebAPI integrates with 3rd Party APIs. Some of those transactional
APIs are very time consuming, so we want to have fire and forget way
of calling those and have them notified when they end.
Once our API receives the response from 3rd party, we want that be notified to UI
So we want some messaging or Pub-Sub mechanism to achieve this
I am in consideration of SignalR and Kafka.
From the documents that I red about SignalR it seems that it can be used between API -client, so I can use this for 2nd scenario.
Can SignalR be used between 2 APIs?
Coming to Kakfa , it seems to be good one for high end data streaming which I consider as over-engineering for our requirement.
Our application will be on both Azure and on-prem so we also went through Azure service bus but there is limit on Message length and cost seem to be problem for us.
So I want to know if there are any ways I can have this communication eased between 2 WebAPIs application?

Azure - Sending data from IoT Hub to Web App Backend

I'm searching for a solution to get data from the Azure IoT Hub to the backend of a Web App also hosted in Azure which is written in ASP.NET 4.6.
It would be best to just receive the raw Json string as fast as possible.
I found others suggesting using Webhooks or Azure functions for a similar purpose but the delay these solutions bring aren't really acceptable.
It would be best to just connect directly to the IoT endpoint and get every message as it comes in. Can anybode please point me to the right direction?
You can simply use the EventHub .NET SDK in your web app, connect to the EventHub-compatible endpoint of the IoT Hub and directly consume the events in your app. This has minimal delay and involves no extra components.
How to guide (.NET core but same applies to .NET Framework): https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-dotnet-standard-getstarted-send#receive-events
var eventProcessorHost = new EventProcessorHost(
EventHubName,
PartitionReceiver.DefaultConsumerGroupName,
EventHubConnectionString,
StorageConnectionString,
StorageContainerName);
// Registers the Event Processor Host and starts receiving messages
await eventProcessorHost.RegisterEventProcessorAsync<SimpleEventProcessor>();
The Azure SignalR Service can help to broadcast messages to the Web App instances.
There are no direct integration between the Azure IoT Hub and Azure SignalR Service. Basically you can use two patterns for this integration such as PULL-PUSH and PUSH-PUSH.
The following screen shows these integration patterns:
Note, that the PUSH-PUSH pattern with the Azure Event Grid is suitable for solution when the subscriber (consumer) is not critical for processing events in the order.

Service Bus architecture for ASP.NET Web API

I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.

can azure service bus (for a topic) send notification to a rest end point (POST)

I need to azure service bus to notify an end point (Rest - POST) whenever a message comes to a particular topic.
In AWS, it is done this way
AWS llink
What is the equivalent in Azure.
Note: I dont want to write code that will receive the message and then call the end point.
Azure Service Bus is a messaging service, not a Notifications service. As such, it deals solely with messaging, and doesn't create notifications for you.
AWS combines SQS (Simple Queuing Service) with SNS (Simple Notification Service) behind the scenes to allow you the functionality you're describing. This is to allow SQS to have a behaviour of events. Azure Service Bus has a native support for Topics and Subscriptions (if that's what you're looking for). I.e. rather than just sending messages to a queue, the message is sent to a topic and appropriate subscriber(s) will get it.
So the short answer to this question in case you don't want to receive the message and trigger a notification is "no".
Saying that, if you're OK with "serverless" functions (similar to AWS Lambdas), you could use Azure Functions to achieve this goal.
Looks like finally azure released Azure Event Grid which kinds of does this out of the box.. very similar to AWS SQS + AWS SNS combo
https://learn.microsoft.com/en-us/azure/event-grid/overview

SignalR Azure Cloud Service with Service Bus

I have built a simple Chat application using SignalR followed the tutorial there, which works great.
Then I followed the tutorial of SignalR Scaleout with Azure Service Bus, also from Microsoft.
So I have completed all the following steps:
Created a new Cloud Service on Azure Portal
Created a new Service Bus namespace on Azure Portal
Created a Windows Azure Cloud Service with a SignalR ASP.NET Web Role
Setup the SignalR Web Role running on 2 instances (VM Size: Small)
Deployed the Cloud Service to the Azure Cloud Service.
But I can't get the SignalR Chat application to work. Can't start the hub.
I noticed it tried to use longPolling and shows status Cancelled/Abort in the browser's debugging tool (Chrome) with the following error in the console:
WebSocket connection to 'ws://example.cloudapp.net/signalr/connect?transport=webSockets&clientProtocol=1.5&connectionToken=KOlz9psd6yCqvYjmCbI3ch5mrXcP%2BAAl3JVMFaP24p2Cv%2FyRb94D5uE27SO9Bz%2B5Itba4vADtv3%2Btv2FMF9LJI6Zxr026UJYxDPNQMVpFTw2hiHd&connectionData=%5B%7B%22name%22%3A%22schathub%22%7D%5D&tid=10' failed: Error during WebSocket handshake: Unexpected response code: 400
and this is the log in the Network:
Do I need to do anything extra besides all the steps listed in the tutorial to make this work?
Based on the current Pricing, you need to set the Service bus to at least Standard tier to support Topics.
In this case, I did create my service bus choosing Standard tier, although it shows Standard on it's Overview page under the "Pricing tier" section, I have to specifically go to the settings and scaled it up from Basic to Standard. Which has solved the problem.

Resources