I need the Notification Message Id that is supposed to be returned from the azure notification hub when sending the message.
I am sending the message from the app backend using the SendGcmNativeNotificationAsync method.
NotificationOutcome outcome = await hub.SendGcmNativeNotificationAsync(notif, tags);
After sending the notification, the outcome.NotificationId property is empty or null. How can I get the Notification Id?
Although the outcome.Result[0].Outcome received has value
"The Notification was successfully sent to the Push Notification System"
but the notifications are not delivered to the registered device.
Also I get a tracking id in outcome.trackingid how can I use it to track the message.
I am using free version of azure portal.
Please suggest
Thanks in advance!
It took me quite some time to figure this out, because it is not clear documented, but the answer is simple: NotificationOutcome.NotificationId is always null when Azure pricing tier is not S1 (Standard).
To figure out the cause of your problem, temporary switch to the S1 pricing tier. Then you will get the NotificationId and Azure will register Per Message Telemetry.
In theory, you should be able to get the results by calling GetNotificationOutcomeDetailsAsync with the NotificationId to get more error info. It can take up to 30 minutes (!) before this call succeeds (if you call it too soon you get a MessagingEntityNotFoundException).
Unfortunately, the result State is mostly Completed, even though the message had a wrong or expired device ID.
The results in the Metrics shown in Azure for your Notification Hub are correct, but I did not find a reliable way yet to retrieve the results on a Per Message base.
Don't forget to switch back to the F1 (Free) pricing tier!
Related
For a few weeks there is an issue with Azure Notification Hub - we have a backend service that registers devices & schedules notifications. When one of the notifications is triggered, then we send it to Azure based on the device type (create the payload and all of that).
The response we get from azure is positive, the notification has been enqueued and is ready to be sent. However, it seems that Azure does not send them all. No error is thrown but only a small percentage is sent. It also does not seem to depend on the device type.
There are no logs to read - or none tha I can find and I cannot pin point the issue.
We have an endpoint that triggers the sending of a notification - we did a test run with 30 notifications (similar and different payloads for the same device) and it all went well.
Not sure how to troubleshoot this or what might cause this. I understood from the documentation that the device might be inactive and then the notification is deleted from the queue after a while. But it seems that the said device receives 1 out of 3 notifications (sent at the same time).
Any feedback would be appreciated.
Edit update:
After upgrading to the Standard plan, we managed to get some more information and it looks like Azure gives back a "Success" with a count of "1" but the device does not receive the notification - the problem is, this happens randomly. It's not always the same device that does or does not receive the notification.
Sorry this isn't a super helpful answer, but could you please open a support ticket in the Azure Portal for us to investigate your particular case? This does not seem like expected behavior so the team will have to look into the logs for your namespace and hub.
One immediate thought - there is de-duplication logic when sending notifications. So within a period of time (something like 15 minutes) if the same notification payload is being sent to the same device, Notification Hubs will automatically drop that duplicate notification.
Scenario
When business transactions are performed, we're supposed to make that data available to end clients.
Current Design
Our web app publishes transaction messages are added to a topic on the Azure Service Bus.
We expose APIs to clients through which they can consume the data from those transactions.
Upon calling these APIs, we read the messages from the Subscription and return it to the client.
Problem
We want a guaranteed delivery - we want to make sure the client acknowledges the delivery of the data. So we don't want to remove the message from the subscription immediately. We want to keep it until the client acknowledges it.
So we only want to do a "Peek" instead of "Receive".
So the client calls the first API, to get the data, where we do a Peek.
And once the client has received the packets, the client would call a second API, to acknowledge.
At this point, we want to remove the message from the Subscription, making it Complete.
The current design of the Service Bus Message Receiver is that, a Complete can be performed only using the same Receiver instance that performed the Peek, as per the documentation, and we also observed the same when we tried it out.
Both the APIs, are two separate APIs and we cannot do the Peek and Complete using the same instance of the Receiver.
Thinking about options to somehow make the Receiver as a Singleton, across APIs within that App Service.
However this will be a problem when the App Service scales out.
Is there a different way to achieve what we're trying to do here ?
There is an option available in Azure Service Bus to defer messages. Once a message is deferred, it can be received with the help of it's sequence number.
The first client should receive the message and instead of completing it, it should defer it and return it.
The second client (which has sequence number) can receive the message from the Subscription. Refer here for more details.
Another option would be to not use a Service Bus Client on your backend and instead your clients could directly work with Service Bus using its Service REST API (assuming they can't use the AMQP client if I am understanding your scenario correctly).
There are APIs to
Peek-Lock
Renew Lock
Unlock
Delete (Complete)
You could also proxy these requests if you'd like using your backend itself or a service like APIM if you are already using it.
PS: Cross posting the answer for the same query on the MSDN forum
Using a Standard Notification Hub, I want to view telemetry for a specific message using the returned NotificationId and either this rest API:
https://msdn.microsoft.com/en-us/library/azure/mt608135.aspx
or the NotificationHubClient GetNotificationOutcomeDetailsAsync method:
https://msdn.microsoft.com/en-us/library/microsoft.azure.notificationhubs.notificationhubclient.getnotificationoutcomedetailsasync.aspx
Either way, I need the Notification Message Id that is supposed to be returned from the hub when sending the message.
I am sending the message from the app backend using the SendTemplateNotificationAsync method:
NotificationOutcome result = await hub.SendTemplateNotificationAsync(params, tags);
After sending the template notification, the result.NotificationId property is empty. How can I get the NotificationId so I can then get the telemetry?
Update:
I tried setting the enableTestSend property to true when creating the NotificationHubClient. The result still does not contain a NotificationId.
Currently there is only one device (installation) registered in the hub. Could this be due to a low number of devices receiving the push?
Posting this for the benefit of others who may encounter this issue.
I was contacted by an Azure support engineer who helped me resolve the problem. I had recently switched from the Free to the Standard tier, and there is a bug in Notification Hubs related to changing subscription tiers. This required the support engineer to "force sync the cache" - which resolved the issue.
The bug has been fixed and will be rolling out soon. If you encounter this issue I would suggest contacting Azure support.
On the pricing page for Azure Notification Hubs:
https://azure.microsoft.com/en-us/pricing/details/notification-hubs/
It states that "Standard namespaces have access to Per Message Telemetry and Push Notification Services Feedback". I am using a Standard namespace.
The app is sending template based notifications to an iOS app from my back end using the C# Notification Hub client. For example:
NotificationOutcome result = await hub.SendTemplateNotificationAsync(params, tags);
The result.State is coming back as Enqueued, but some notifications are not being delivered and I am trying to figure out why. (There are no bad registrations in the hub - I have already checked that.)
In the Azure portal, I can see aggregate metrics of messages received by the hub, errors, etc. - but I cannot seem to view the specific results of a push message to determine why it failed to reach the device, or even if it was successfully handed off to APNS.
How can I see the results of an attempted push? Is this even possible with Azure Notification Hubs?
Did you try Fiddler+https://msdn.microsoft.com/en-us/library/azure/mt608135.aspx ?
Also, as far as i know, Apple does not guarantee the delivery of all notifications.
1) Is Apple's push notification service reliable?
More of that,
2) https://azure.microsoft.com/en-us/documentation/articles/notification-hubs-faq/
"A PNS does not guarantee any SLA for delivering notifications; however, typically a vast majority of push notifications are delivered to target devices within a few minutes (usually within the limits of 10 minutes) from the time they are sent to our platform. "
Is it possible to send a message directly to a Subscription queue?
Scenario:
A message failed, dropped onto the deadletter, the message has been picked up manually using defer, cloned and needs to be sent to the queue it was first deadlettered on, but NOT the topic.
Can I send a message directly to a subscriber?
I've considered creating a separate retry queue per subscriber, where the handling service will also receive messages from but i'd rather not do this.
this is a similar question to the one you asked earlier: Azure Service Bus Subscriber Deadletter
this is not possible, as far as I know. the only thing you could do is to add an extra filter on every subscription that has something like SubscriptionName='SubscriptionA'. If you then want to send you deadlettered message to the specific subscription, you can add a property SubscriptionName to it, to achieve your goal. Take into account that you also have to make sure that in your original filter, you add a condition to indicate that the property SubscriptionName should not exist.
I agree however, that it would be a nice scenario to 'undeadletter' a message, so that it ends up again in his original subscription.