Я новичок в разработке Exchange (2007), поэтому, пожалуйста, потерпите меня. :-). Похоже, существует множество технологий для разработки Exchange, последняя из которых - веб-службы Exchange, и связанный с ней управляемый API. Мне нужно написать программу, которая может - при необходимости - запускаться на серверах Exchange - для сканирования почтовых ящиков людей с целью очистки сообщений, соответствующих различным критериям (не относящимся к этому обсуждению).
Насколько я понимаю, большинство других технологий - WebDav, MAPI, CDO - в настоящее время устарели в отношении Exchange 2007 и Exchange 2010. Поэтому, поскольку это новое приложение, я решил использовать веб-службы Exchange. Управляемый API.
Меня беспокоит количество элементов, которые я могу сканировать за час . Так как он основан на веб-сервисах, здесь задействован сетевой переход. Поэтому я хотел бы запустить эту утилиту на сервере, с которым я общаюсь. Правильно ли я должен говорить с сервером "Hub"? . Я использую автоматическое обнаружение, и оно, похоже, разрешает серверу-концентратору независимо от того, какой почтовый сервер содержит фактическое хранилище сообщений, которое я сканирую.
При перетаскивании нескольких элементов - используя ExchangeService.FindItems и указании размера страницы 500 - я получаю довольно хорошую пропускную способность от моей рабочей станции до хаб-сервера. Мне удалось получить 22 000 почтовых отправлений за 47 секунд. Это кажется разумным. Однако , оказывается, что не все свойства «связаны» при получении таким способом. Некоторые свойства, такие как ToRecipients и CcReipients, не заполнены. Вы должны явно связать их (индивидуально) - с помощью вызова
Item.Bind(Server, Item.Id)
Это отдельная передача в оба конца на сервер, которая снижает пропускную способность примерно с 460 элементов в секунду до 3 элементов в секунду, что невозможно.
Итак - несколько других вопросов. Есть ли способ принудительно связать отсутствующие свойства во время вызова FindItems? Если это не удастся, есть ли способ связать несколько элементов одновременно?
Наконец, я прав в выборе веб-служб Exchange вообще для этого типа работы. Я люблю простоту модели программирования и не хотел бы переходить на другую технологию, если она (а) более сложна или (б) устарела. Если другая технология сделает эту работу лучше, и это не устарело, я бы подумал использовать ее в случае необходимости. Ваше мнение и советы приветствуются.