I'm working on a sync server that keeps the Office 365 events and my calendering app in sync. I subscribed to a push notification for user's event calendar that has a custom single extended property.
The documentation says if the sync server doesn't respond with a 2xx message, the notifications will be resent in periodic intervals. I tried by bringing my server down for some time and in this interval I did some changes to the events for which I was expecting notifications. Then I brought the server up again and it took some time(10-15 mins) for Microsoft to send old queued notifications.
Any idea what is the interval that Microsoft sends queued notifications when 2xx is not received?
Related
Can someone tell me what the behaviour is when a Graph change notification is attempted to be sent to the configured endpoint (notificationUrl) but the endpoint is unavailable (e.g. your in the process of a release or the endpoint is just not there for a while)?
I can see that I am getting a repeated notification delivery attempt every 5 minutes, but does that eventually stop? Does it become a 'missed' lifecycle event at some stage? Or does it keep trying endlessly?
thanks
The service will retry for a few hours.
If the notification URL is unresponsive or slow for more than 10% of delivery attempts, notifications will be paused and retried in a couple of hours.
If the notification URL is unresponsive or slow for more than 20% of delivery attempts, notifications will be dropped.
Unresponsive notification URL will not result in a missed lifecycle notifications. Those are only sent when the service was not able to emit notifications due to other reasons.
I want to make an application exactly like the title. Every 5 or 15 minutes in the background, I will send a request to the api which I made and send a notification to my phone according to the results.
I used the react-native-notifications and react-native-background-timer plugin but when I lock my phone or close the app, notifications are not received. (IOS)
I struggled for a week, I couldn't do it.
I'm waiting for your help.
After registering to webhook subscription for mail or user resources - What is the expected time between a change occur till our subscribed endpoint will receive the change notification?
The time to deliver notifications varies depending on the service load and other factors. Under normal conditions you should receive notifications within 5 minutes of the actual change.
I would like to use the Outlook REST API webhooks / subscriptions to update calendar events in my application. I couldn't find any information in the documentation regarding whether the Outlook API will retry sending Notifications if my application is down / crashed or sends a 500 error. I know the Google API uses exponential backoff to retry sending. Does Outlook do something similar?
Thanks,
Adam
Yes. From the Microsoft Graph documentation:
When the subscribed resource changes, the webhooks facility sends a notification to your notification URL with the following payload. The notification endpoint must send a response of 200 or 204 with no response body within 30 seconds otherwise the notification attempt will be retried at exponentially increasing intervals. Services that consistently take 30 seconds or more may be throttled and receive a sparser notification set.
Is it possible to send multiple (10 - 15) notifications to the registered iOS users at a time / instantaneously ? What are the limitations for iOS Push Notifications ?
Is it possible to send multiple (10 - 15) notifications to the registered iOS users at a time / instantaneously ?
No you can not send 10-15 notification simultaneously to same user, read more here at apple docs .
If you are sending multiple notifications to the same device or
computer within a short period of time, the push service will send
only the last one.
However if you intend to send push notifications to different users at same time than it should be no problem (Which i guess is what you are looking for).
What are the limitations for iOS Push Notifications ?
If you are not sending them simuntanously to same user than there is no limitation for APN's push notification as mentioned here .Take a look at Push Notification Throughput and Error Checking
There are no caps or batch size limits for using APNs. The iOS 6.1
press release stated that APNs has sent over 4 trillion push
notifications since it was established. It was announced at WWDC 2012
that APNs is sending 7 billion notifications daily.
If you're seeing throughput lower than 9,000 notifications per second,
your server might benefit from improved error handling logic.
Here's how to check for errors when using the enhanced notification
format. Keep writing until a write fails. If the stream is ready for
writing again, resend the notification and keep going. If the stream
isn't ready for writing, see if the stream is available for reading.
If it is, read everything available from the stream. If you get zero
bytes back, the connection was closed because of an error such as an
invalid command byte or other parsing error. If you get six bytes
back, that's an error response that you can check for the response
code and the ID of the notification that caused the error. You'll need
to send every notification following that one again.
Once everything has been sent, do one last check for an error
response.
It can take a while for the dropped connection to make its way from
APNs back to your server just because of normal latency. It's possible
to send over 500 notifications before a write fails because of the
connection being dropped. Around 1,700 notifications writes can fail
just because the pipe is full, so just retry in that case once the
stream is ready for writing again.
Hope this helps.
If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one.
Here's why. The device or computer acknowledges receipt of each notification. Until the push service receives that acknowledgment, it can only assume that the device or computer has gone off-line for some reason and stores the notification in the quality of service (QoS) queue for future redelivery. The round-trip network latency here is of course a major factor.
As described in the Local and Push Notification Programming Guide, the QoS queue holds a single notification per app per device or computer. If the service receives another notification before the one in the queue is sent, the new notification overwrites the previous one.
All of this points out that the intent is that a notification indicates to an app that something of interest has changed on the provider, and the app should check in with the provider to get the details. Notifications should not contain data which isn't also available elsewhere, and they should also not be stateful.
Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point.
for more info click here