Now I have subscribed a push notification to EWS to receive Create or New mail events, but sometime I can’t get heartbeat event from EWS more than one hour.
So, if I want to check whether these push notification subscriptions succeed, is there any tool to check it directly?
Thanks in advance!
No, there is no way of enumerating the current Push subscriptions on a Mailbox, if you successfully subscribed to a Push notification then you would have got a response with the SubscriptionId and status success. To keep a push notification active you need to respond to the heart beat messages which will contain the SubscriptionId (you get at the time of subscription) which are sent every minute see https://blogs.msdn.microsoft.com/webdav_101/2014/04/17/ews-push-what-is-the-statusfrequency-for/ for details on the status frequency . If you have access to the server then server will log errors if it can't successfully send a push notification
Typically with Push notifications the issues are with the server communicating to your listener is that end point isn't reliable or accessible from the server. But the server Subscription can go away without notice if there is a Server issue, so your code needs to track the lack of status update from the server as a sign there maybe problems with the subscription there's a good sample https://blogs.msdn.microsoft.com/emeamsgdev/2011/08/19/ews-push-notification-example-application/ .
Streaming subscriptions can be a better fit for push notification application from a client application persepctive because the client connectivity is a lot more flexible, you can also easily check if a SubscriptionId is still available using a GetEvents request etc. Although if your using Office365 the new Webhooks in the REST API are a much better overall approach.
Cheers
Glen
Related
Exchange 2010.
I've read about notification subscriptions, mailbox events, and EWS in Exchange and as i got it, the notiified client app have to stay connected to EWS all the time. Am i right?
My task looks easy - i need to trigger some action (web call most likely) when message arrives to mailbox. Is there anything for such task in EWS 2010? Is there anything like this in latest versions of Exchange Server on-prem?
For now I'm starting to think about forwarding email via trasnport rules to some unix-mta for further processing.
Yes that's correct EWS notifications require that the client application that receives the notifications stay connected if your using Stream notifications. Pull notification don't and push notifications don't but the client does need to be available to receive the heartbeat messages and then update the subscription.
There is nothing new in the later OnPrem version of Exchange there are web-hooks in Exchange Online in the Graph API
If the device is offline for some period, APNS will only keep the last notification and re-send it when the device is back-online. My question is, if Parse or any other Push serivces provider has a feature to re-send the notifications that I missed during the offline period. If not, is there any way I can achieve this with current Parse features?
You can configure parse to send notifications when they became available https://www.parse.com/tutorials/ios-push-notifications
When a user's device is turned off or not connected to the internet,
push notifications cannot be delivered. If you have a time sensitive
notification that is not worth delivering late, you can set an
expiration date.
Also check here
Is there any way we can know when a consumer disconnects from a queue or when a queue is deleted?
The requirement is as follows:
I'm building a system in which multiple clients can subscribe to certain events from the system. All clients create their own queue and registers themselves with the system using some sort of authentication. The system, as the events are generated, filters the events and forwards them to clients who are eligible for them.
I have implemented a POC for most part of it and it works well. An issue that I'm not able to fix is that, if a client just disconnects from the queue (due to program termination or so), the registration still exists and the system keeps trying to push messages to that client.
So we would like to be notified when a client disconnects or a queue gets deleted so that we can remove that client's registration data and no longer push messages to him.
Let your publisher utilize Confirms (aka Publisher Acknowledgements) and make client queue be exclusive and transient, so only one client at a time will be consuming from one queue and after it disconnection it will be deleted.
If you publish message that get routed to only one queue and that queue gone (assume you utilize publisher confirms and publish message with mandatory flag set) publisher will be notified that message cannot be routed with that message returned back to it, so you can stop publishing messages.
For details see How Confirms Work section in RabbitMQ blog post "Introducing Publisher Confirms" and Confirms (aka Publisher Acknowledgements) official docs.
I have a few problems listening to incoming invitetions,
1) onInvitationReceived is not called when an invite is received when app on (i registerInvitationListener to my gamesClient in onSignInSucceeded)
2) no notification will pop up when the app isnt open aswell.
i was trying to add plusClient in the BaseGameActivity but still no change, is something need to be done to make the app listen to invites that im missing?
do i need to publish it to see invite notifications?
sending invites to someone that doesnt have the app should send him to google play?
Invitations are delivered via push notification (like GCM), so several factors may influence in the system's ability to deliver them. If you don't get invites through the notification bar, there is something wrong with the network or with the device. Push messages are somehow not getting through to it. Can you send a gtalk ping to the device, and does it appear on the notification bar?
Once you do get to a state where notifications via notification bar are showing, but are not able to receive them in your app, I'd check:
(1) Are you registering an anonymous listener as an invitation listener? That's problematic. Take a look at this tip.
(2) Are you waiting a sufficient amount of time? Sometimes it may take > 30sec before a notification arrives, depending on network connectivity. With good network it should be faster, though.
We are developing a Newsstand app, and are currently working on the push notification to let users know a new issue has arrived. From the ambiguous Apple documentation it looks like we will need to send a separate push notification for each user that downloaded the app; each notification should contain a unique device token for each app instance.
The section titled Trust Components seems to imply that you can use the device token or the certificates to authenticate your push notification, but it also implies you need both.
Is it correct that we will need to send out a separate push notification for each installed instance? Can we really not send one push notification and have Apple notify all the users of the app that a new issue has arrived?
Short answer is YES the statement you made is correct.
You have to send out push notification to each device token which must be stored in your server (provider). The preferred way to send multiple notification is to not make multiple connections but reuse one to send multiple notifications. Below is the paragraph from Apple Doc
You should also retain connections with APNs across multiple
notifications. APNs may consider connections that are rapidly and
repeatedly established and torn down as a denial-of-service attack.
Upon error, APNs closes the connection on which the error occurred