While researching Azure Notification Hubs, I saw there are two Telemetry options available (source):
"Limited"
"Rich"
Although I have found very limited descriptions on the Pricing and the FAQ pages, this is not enough information to make a decision whether I want the "Rich" telemetry or if the "Limited" Telemetry is enough. Additionaly, those descriptions only talk about the "Rich" option:
Standard namespaces have access to Per Message Telemetry and Push Notification Services Feedback
Rich telemetry: You can use Notification Hubs Per Message Telemetry to track any push requests and Platform Notification System Feedback for debugging.
Also, a Tweet asking #AzureSupport for help only lead to the FAQ page and eventually led them to ask me if I could ask this very question on SO.
The only option available next to asking here is to actually try out, but that would incur a monthly fee and extra effort.
The main difference between the two is that "limited" gives you access to counts of various events: registrations, sends etc; pretty much everything you see as graphs in Azure Portal on Notification Hubs blades.
"Rich" (or Per Message Telemetry) gives you access to detailed information about every single push: things like feedback from PNS and many other things. You can think about it as if you were to send requests directly to PNS yourself and log pretty much any meaningful information about those.
Let me know in the comments if I can clarify.
I finally found a useful MSDN page, which has some answers to what telemetry is provided, how, and to who. It says "This API is only available for Standard tier notification hubs" which means Rich Telemetry only, not Limited.
If the PNS platform involved supports it, then Success means it was delivered to the device. Oddly, despite copious other error codes, there seems to be none for "accepted by PNS, but still not/failed to deliver to device."
It provides counts of outcomes, so if you want per-device results, you'll have to send to only to one device at a time.
Related
This is part public awareness and part actual question for better workarounds.
Overall, we have recently discovered (the hard way) that emailing via an Azure Action Group is unreliable and occasionally fails. Basically, sometimes their IPs get blacklisted for various reasons (very common). They have nothing in place to alert those relying on an email notification that it failed, even though they have all the information they need to do so (they showed me a screenshot showing the SMTP failure due to the IP blacklisting from their log). The Azure portal will still show "fired". And, so, it just fails silently in the background with no indication to the user it was never sent. According to one of the technical Azure reps we have discussed this with:
The way of identifying a failure is to evaluate any kind of rejection message received from the target server but those are not guaranteed and not generated in all scenarios. Take into account that email actions are provided free of charge and performing post-send operations to try and verify delivery would consume additional computing that would make providing this notification mechanism free of charge less desirable
I know that many rely on these for production notifications of various scenarios. You should not rely on this going forward, or at least have a backup in place (e.g. SMS, web-hook, etc).
I would like to know if anyone has experienced this as well and, if so, what is the better, more reliable method to use.
Thanks in advance!
I am using UPS APIs to figure out ratings and create shipments and now I'd like to track shipments in real time. I know there are a lot of services that provide tracking aggregation for different couriers, including UPS, via webhooks, but I am looking for a "native" UPS API for the real time tracking that would not require me to keep poling for updates.
I went over the UPS API docs and could not find anything. Is there such an API that offers webhook type notifications or something similar in UPS? If not, how do those services like EasyPost, ParcelMonitor, TrackingMore and others can offer such functionality?
I'd like to track shipments in real time
"Real-time tracking" is a misnomer in the shipping technology industry. EasyPost does provide webhook events to notify you of updates, but those updates will never come in "real-time" and no tracking service provider should ever make such a claim. There will always be some kind of delay between when the carrier updates their system and when the updates are able to flow through providers like EasyPost. The delay may be short, but any delay at all means that "real-time" goes out the window.
Being an EasyPost employee myself, I have to disclose my bias and say that I believe EasyPost can help you get updates as promptly as possible for UPS shipments.
The nice thing about setting up webhooks with EasyPost is that you don't have establish your own logic to repeated poll for new tracking updates. This can save you network bandwidth and reduce the complexity of your code and it can help you get updates sooner than if you were trying to poll updates on your own intermittent schedule.
We're trying to setup a referral tracking program for a chrome extension we developed. To track reoccurring subscriptions we'd like to be able to poll the Subscription Status and I was able to find google.payments.inapp.getPurchases in their documentation here: https://developer.chrome.com/webstore/payments-iap#get-purchases
I was wondering if it was possible to poll for the order number associated with the purchase. This seems to be a way to uniquely tie and track a user to a subscription and also lets us correlate the info available on pay.google.com
Any suggestions or information is appreciated! Thanks.
Response I got back from the Chrome Developer Support:
Thank you for contacting Chrome Web Store Developer Support! In
regards to your question, unfortunately, we are not supporting polling
the associated order number at the time. However, I absolutely agree
with you that it would be very helpful for our developers in the CWS.
I'll be glad to convey your message to the pertinent team to discuss
this topic.
I figured out that there's always latency of about two to three seconds when sending messages through the Bot Connector of Microsoft's Bot Framework independent of which channel type I'm using.
This means if I call the POST .../messages API method of my Bot directly (so not going through the Bot Connector) I get an answer within several dozens ms. However, if messages are routed through bot connector (e.g. when I use Direct Line communication or Telegram or any other supported channel) it always takes about two to three seconds until I get an answer.
For a possible user this would not be a good user experience so that I'm wondering whether either I'm doing someting wrong (e.g. Bot Connector settings) or whether this is a general problem and will be improved at a later pont of time.
Thanks a lot in advance.
This is a known issue. The BotFramework is still in Preview, so it has yet to be optimized. Expect to see significant performance improvements in the near future.
I have experienced significant variability when using the Instagram Subscription API. For the most part, the API will not post updates to my end-point as specified during the subscribe initiation. My understanding is that the subscription is configured correctly as any of the updates from my personal account are received.
There seem to be reports across the web talking about significant delays. However, it is my experience that accounts that work do so within seconds but in most instances no subscription messages are never received.
There was discussion on the web also regarding queuing of updates sent through to the subscribe API. Which may make a little sense, however a queue would suggest that updates would be received eventually.
I have requested basic permissions, which is sufficient to request public media from each registered account. Yet, there I have a gut feeling that these permissions could be the problem, so I have started the process of requesting public_content.
At this stage there seems to be a number of developers experiencing similar issues, yet no resolutions.
Has anybody been able to resolve this issue?
I'm subscribed to aspect=media object=user and experiencing a similar issue.
For some users, I'm notified 95% of the time. For other users, I've never been notified of a single post.
In this post nithinisreddy mentions that the data is being "sampled". I think this is the reason. Hopefully it improves after the tags/locations subscriptions are deprecated.