Does anyone know if Azure Bot's Directline call to refresh token is free or will use the messaging quota? The free one has 10,000 messages/month and S1 package is RM$2.10 per 1,000 messages. This is because the token will expire after 30 minutes, and we want to auto refresh it before 30 minutes.
Does anyone know where to check the quota usage of the 10,000 messages?
In the Azure Portal's Web App Bot's Analytic page, it shows the number of activities, not sure if it is same as the 10,000 messages?
Thanks
Each activity is a message. From this page:
Bots communicate with the Bot Service channels by sending Activity
objects to the channel endpoint via HTTP POST, and by Activity objects
being sent to the Bot’s endpoint via HTTP POST. Each of these Activity
POSTs is a message.
No, they do not count. The calls to refresh the token are not activities, therefore not messages.
Yes, the analytics page is the correct place.
Related
I have been testing around with the Azure App Services and got this error
App Service Plan Create operation is throttled for subscription.
As I understand I created too many apps in a short period, how long until I can create a new app again?
Thank you
I began receiving this error, but without the Retry-After property in the response. After working with Azure support, it turns out newly-created subscriptions take a while to fully allocate in the background. We had to wait 48 hours before the throttling error would go away, and that was what Azure support validated with us.
Once the 48 hours passed (and the new Azure sub was presumably complete in its creation), we no longer received the errors.
As I understand I created too many apps in a short period, how long
until I can create a new app again?
We dont have any ideal time that how long until you have to wait to create a new app again.
Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant.
When you reach the limit, you receive the HTTP status code 429 Too many requests. The response includes a Retry-After value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned.
You can determine the number of remaining requests by examining response headers. Read requests return a value in the header for the number of remaining read requests. Write requests include a value for the number of remaining write requests.
You refer this documentation,on how to Retrieving these header values in your code.
Is there any way to implement a Webhook for automatic update of subscriptions on server side, in nodejs for example, for situations such as: the user renewed or canceled his subscription?
Currently I save the subscription data in my Database after purchase and use the Google Developers API to verify that it has been renewed or canceled when necessary.
However, for some Administrator routines I need to check all subscriptions at once and this includes calling the Google API for each one. This process is slow and can take a long time.
I could create a method that checks and updates all subscriptions according to the Google API response, and leave this process running through a Cronjob every day at night. I believe it will work, but a server-side Webhook would be the ideal solution.
Something which automatically notifies my server as soon as there is a change to a subscription so that I can update it in my DB immediately.
Found the answer. We can use Google Cloud Platform (GCP) to subscribe to topics and receive real-time notifications when a subscription change.
All steps are described in detail in their documentation: https://developer.android.com/google/play/billing/getting-ready#configure-rtdn
Is there any way to send activities that are happening in external application to ms teams activity feed through any api.Now I have designed a blog where other users can like comment and follow my post in the blog.So I want to get all the activities that are happening in my blog to ms teams.
The Microsoft Graph REST API uses a webhook mechanism to deliver change notifications to clients. A client is a web service that configures its own URL to receive notifications. Client apps use notifications to update their state upon changes.
subscription operations require read permission to the resource. For example, to get notifications for messages, your app needs the Mail.Read permission.
Please look at change notification API
I am creating a bot using Microsoft Bot Framework (BotBuilder) and want it to message the user when an appointment is about to begin.
I currently use Microsoft Graph api to access the user's Office 365 calendar and store the appointments. A background thread then keeps track of time and then messages the user when an appointment is about to start.
The current idea is to use Graph webhooks to notify my bot about new appointments.
My question is, would it be smarter to use an Azure service (such as Scheduler) to keep track of the appointments, and send rest messages to my bot, which will then send a message to the user?
My worry is, that as the amount of users rise, the amount of appointments and time checks will become too large, and that maybe Azure services would be able to handle it better.
This is a perfect fit for Azure Functions with a HTTP Trigger.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook
This article explains how to configure and work with HTTP triggers and bindings in Azure Functions. With these, you can use Azure Functions to build serverless APIs and respond to webhooks.
Azure Functions provides the following bindings:
An HTTP trigger lets you invoke a function with an HTTP request. This can be customized to respond to webhooks.
An HTTP output binding allows you to respond to the request.
Now I'm using PushSharp library to send Apple push notifications (through APNS), but I want to migrate to Notification Hubs for robustness and scalability.
I'm planning to implement sending notification via Azure Notification Hubs using backend registration as described in this article. So:
There is a method of backend API that an iOS client calls when it has push token updated. In this method I do the registration tagging it with user id. (Previously, I stored push token to user link in DB.)
When I have some notification to send for a specific user I send it using the tag (user id). (Previously, I used APNS device token from DB.)
It seems like a working solution, but in Notification Hubs documentation it's said:
It is important to note that registrations are transient. Similar to the PNS handles that they contain, registrations expire. You can set the time to live for a registration on the Notification Hub, up to a maximum of 90 days. This limit means that they must be periodically refreshed, and also that they should not be the only store for important information. This automatic expiration also simplifies cleanup when your mobile application is uninstalled.
And that is the problem. Sometimes I need to send notification to devices that haven't updated the token for 90 days and so forth the registration. So the APNS token will still be active, but Notification Hub's registration will be invalidated. So I just lose the communication channel for the user.
How do you handle this?
Of course, I can still store tokens in DB and make a job that updates registrations periodically. But that's not what you expect from a push notification solution like Notification Hubs.
You can either refresh your registrations from the application or from your server. If you do it from your application, the app must be launched by the user in order for the registration to be refreshed.
Therefore, if you require that device registrations remain active even for apps that weren't launched for over 90 days, you have to refresh the registration via your server, and running a job in your server that would refresh the tokens seems like your only option.
I agree that Notification Hubs' decision to expire the tokens seems strange. Perhaps they had in mind the behavior of MPNS (Microsoft Push Notification Service) notification channels, which expire more often than APNS device tokens or GCM registration IDs.
Just a quick note, since the answer is 2 years old. In this blogpost Azure states:
It is important to note that registrations and installations by default no longer expire.
I assume that this makes the expire field confusing, but not a problem anymore.
UPDATE
Older notification hubs still have this issue. You need to update them to set the expiry to infinity, instructions are found in this forum post. New hubs are automatically set to infinity.
As per latest notification hub documentation, this 90 days limit has increased to lifetime, which means you don't need to re register device after 90 days.