EWS API - Помилка при відтворенні підписок на сповіщення


81

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

Перевіривши рекомендовану корпорацією Майкрософт обробку помилок , рішення полягає у використанні функції Автовизначення для повторного відкриття ExternalEwsUrl або EwsPartnerUrl та створення нової передплати.

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

Однак, коли я намагаюся створити нову передплату для певної папки календаря, я продовжую отримувати загальний 500 ErrorNoRespondingCASInDestinationSite помилку:

Наразі веб-служби Exchange не доступні для цього запиту, оскільки жоден із серверів клієнтського доступу на цільовому сайті не може обробити запит.

Дивна частина полягає в тому, що це відбувається лише безпосередньо після отримання початковогоErrorReadEventsFailed помилки . Якщо я спробую ще раз, скажімо, через 30 секунд, запит пройде без проблем.

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

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

Будь-яка допомога буде вдячна!


Майже рік, чи знайшли ви рішення для цього?
Маркус Хьоглунд,

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.