Exchange Online推送通知订阅无法永久保存

本文介绍了Exchange Online推送通知订阅无法永久保存的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我从一位同事那里继承下来，他留下了一个与Office 365中的Exchange Online集成的系统模块.本质上，该模块的作用是通过 EWS托管API ； 订阅有关推送通知的更改用户的日历.

I have inherited from a colleague who left a system module that integrates with Exchange Online in Office 365. Essentially what this module does is interact with with the remote Exchange service via EWS Managed API; subscribe for push notifications on changes in a user's calendar.

更改事件确实会发布到我们的Web服务中，这很好.根据我们定义的 frequency 参数，状态检查消息也会按预期的时间间隔有关订阅保持活动行为的说明.

Change events do get posted to our web service and that is fine. And based on the frequency parameter we defined, the status checks messages also get posted on expected intervals, as per description about the subscription keep-alive behaviour.

从问题上看，问题是，尽管使用SubscriptionStatusType.OK进行响应以使订阅保持进行下去，但该订阅并没有永久存在.我们从不发送SubscriptionStatusType.Unsubscribe，因为在消息的通知中没有发现错误情况. Exchange服务停止发送任何状态检查或更改通知消息似乎只持续9到14个小时.当我们从两个单独的Web服务器(不同的通知回调URL)进行订阅时，它们的订阅似乎在同一时间消失.

The problem is, in observation, the subscription does not perpetuate despite responding with SubscriptionStatusType.OK to keep it ongoing. We never send SubscriptionStatusType.Unsubscribe since there is no error condition found in notification in messages. It seems to only last 9 to 14 hours before the Exchange service stops sending any status checks or change notification messages. When we make subscriptions from two separate web servers (different notification callback URLs), their subscriptions seem to die out around the same time.

没有发现任何可能导致Exchange服务取消/终止我们的订阅的线索.还有什么其他条件可能导致这种提前退订?

Haven't found any clues that would cause the Exchange service to cancel/expire our subscriptions. What other conditions might contribute to this premature unsubscribe?

推荐答案

Exchange会相当定期地丢失"订阅，尤其是在O365环境中，因为邮箱会不断地拖曳到不同的服务器上，以便对整个服务器进行负载平衡生态系统.即使在本地Exchange中，如果CAS重新启动，您也可能会丢失订阅.不幸的是，要构建一个可靠的应用程序，您必须通过某种通知或心跳定期检查您是否从Exchange收到了消息.

Exchange will "lose" subscriptions on a fairly regular basis, especially in the O365 environment because mailboxes are continually being shuffled onto different servers in order to load balance the entire ecosystem. Even in an on-prem Exchange you can lose subscription if a CAS restarts. Unfortunately to build a reliable app, you have to check periodically that you heard from Exchange via some kind of notification or heartbeat.