EWS API - Ошибка при повторном создании подписок на уведомления

81

При работе с подписками по запросу на папки календаря Office365 я получал много ErrorReadEventsFailedсообщений в SendNotificationзапросе. По сути, эта ошибка означает, что подписка больше не может быть найдена, и сервер больше не должен ожидать новых уведомлений.

Проверяя рекомендованную Microsoft обработку ошибок , решение состоит в том, чтобы использовать автообнаружение для повторного обнаружения ExternalEwsUrl или EwsPartnerUrl и создания новой подписки.

В Office365 служба AutoDiscovery кажется практически невозможной с комбинацией учетных записей служб OAuth2, поэтому я использовал ее https://outlook.office365.com/EWS/Exchange.asmxв качестве основной конечной точки EWS.

Однако, когда я пытаюсь создать новую подписку для определенной папки календаря, я продолжаю получать общую 500 ErrorNoRespondingCASInDestinationSiteошибку:

Веб-службы Exchange в настоящее время недоступны для этого запроса, поскольку ни один из серверов клиентского доступа на конечном сайте не может обработать запрос.

Странно то, что это происходит только сразу после получения начальной ErrorReadEventsFailedошибки . Если я попробую еще раз, скажем, через 30 секунд, запрос будет выполнен без проблем.

После некоторого исследования выяснилось, что большинство пользователей сочли полезным убедиться, что X-AnchorMailboxзаголовок установлен правильно для пользователя, которого учетная запись службы желает выдать себя за другое лицо. Я дважды проверил этот заголовок, и он действительно отправляется вместе с запросом на повторную подписку.

Эта проблема может быть решена с помощью решения с экспоненциальной отсрочкой или просто повторением попыток X раз, пока запрос не будет выполнен. Мне кажется, что когда подписка «теряется», службе O365 нужно время, чтобы сменить DNS сервера Exchange (это единственное, что я могу придумать).

Любая помощь будет принята с благодарностью!

exchange-server  office365  exchangewebservices 
— Jstruzik
источник
Почти годик, вы нашли решение для этого?
— Маркус Хёглунд
1
Ничего официального, но я реализовал своего рода стратегию «повторной попытки», чтобы попытаться смягчить проблему. К сожалению, проблема все еще возникает даже после добавления X-AnchorMailboxзаголовка и использования файла cookie серверной части Exchange во всех запросах. Кажется, исправляется сверхурочно (от 30 секунд до целого дня).
— jstruzik
3
Хорошо, я также реализовал стратегию повтора. Больше всего беспокоит то, что иногда при возникновении этой ошибки единственное, что мне нужно сделать, это воссоздать подписку на текущую службу EWS. Но когда это не сработает, мне нужно создать новый экземпляр службы и вызвать автообнаружение, чтобы заставить его работать. Я думаю, что сервер обмена что-то делает (чистит, переподключается ... просто догадывается.), И если этот процесс займет слишком много времени, вы получите вот это ...
— Маркус Хёглунд

Ответы:

3

Учитывая документацию по адресу: https://msdn.microsoft.com/en-us/library/office/dn458788(v=exchg.150).aspx

Если подписка потеряна или больше недоступна, лучше всего создать новую подписку и не включать старый водяной знак в новую подписку. Повторная подписка со старым водяным знаком вызывает линейное сканирование событий, что требует больших затрат.

Вместо этого создайте новую подписку и сравните свойства папки, чтобы найти изменения содержимого, которые произошли между потерянной подпиской и новой подпиской. Рекомендуем вам проверить расширенные свойства папки PR_LOCAL_COMMIT_TIME_MAX (0x670a0040)и PR_DELETED_COUNT_TOTAL (0x670b0003).

Вы можете сделать это, создав расширенное определение свойства. Я думаю, это может вам помочь !!

— Манодж С
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.