【问题标题】:Exchange Online push notification subscription unable to perpetuateExchange Online 推送通知订阅无法永久保存
【发布时间】:2015-01-17 04:37:13
【问题描述】:

我从一位同事那里继承了一个系统模块,该模块与 Office 365 中的 Exchange Online 集成。本质上,该模块的作用是通过EWS Managed API 与远程 Exchange 服务进行交互; subscribe for push notifications 用于用户日历的更改。

更改事件确实会发布到我们的 Web 服务,这很好。根据我们定义的 frequency 参数,状态检查消息也会按预期的时间间隔发布,as per description about the subscription keep-alive behaviour

问题是,在观察中,尽管使用 SubscriptionStatusType.OK 进行响应以使其继续进行,但订阅并没有永久存在。我们从不发送 SubscriptionStatusType.Unsubscribe,因为在消息通知中没有发现错误情况。在 Exchange 服务停止发送任何状态检查或更改通知消息之前,它似乎只持续了 9 到 14 小时。当我们从两个不同的 Web 服务器(不同的通知回调 URL)进行订阅时,它们的订阅似乎几乎同时消失。

没有发现任何会导致 Exchange 服务取消/过期我们的订阅的线索。还有哪些其他条件可能导致这种过早退订?

【问题讨论】:

    标签: exchange-server exchangewebservices


    【解决方案1】:

    Exchange 会定期“丢失”订阅,尤其是在 O365 环境中,因为邮箱不断被转移到不同的服务器上以平衡整个生态系统的负载。即使在本地 Exchange 中,如果 CAS 重新启动,您也可能会失去订阅。不幸的是,要构建可靠的应用程序,您必须定期检查您是否通过某种通知或检测信号从 Exchange 收到消息。

    【讨论】:

    • 你从哪里获得这个实现细节?因此,在微软将订阅的持久性改进为与 CAS 无关之前,我们似乎被搞砸了。
    • 这是从多年编写和支持使用推送(现在是流)通知的应用程序中学到的。我曾与 MS Support 就该领域的许多问题进行过合作。我不确定这是等待 MS 更改 CAS 的问题,我也不一定认为我们“搞砸了”,在处理网络世界中的不可靠性方面面临着巨大挑战。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-19
    • 2021-10-16
    • 1970-01-01
    • 2019-09-24
    相关资源
    最近更新 更多