Основы разработки под Microsoft Exchange Server

в 7:43, , рубрики: api, exchange, mail, microsoft, powershell, rest api, Блог компании Microsoft, почта, Программирование, Серверное администрирование, сообщения

На форуме TechNet Microsoft каждый день появляются новые вопросы, касающиеся разработки для ExchangeExchange Online. Актуальными на сегодняшний день являются два метода разработки: с использованием веб-сервисов (EWS Exchange и другие) и без их использования. В этой статье рассмотрим оба варианта и обозначим их плюсы и минусы.

Основы разработки под Microsoft Exchange Server - 1

Передаю слово автору.

Microsoft Exchange Server — серверный программный продукт для обмена сообщениями и совместной работы. Exchange предоставляет не просто очень мощную систему обмена сообщениями E-Mail, но качественно более обширный диапазон функционала. Помимо функции почтового сервера, Exchange можно использовать для обмена документами, создания общих календарей, обмена голосовыми сообщениями и многое другое. Более подробно о Exchange Server можно узнать на сайте.

История продукта более подробно описана по ссылке.

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

Основные цели для разработки следующие:

  1. Выполнение требований-ограничений
  2. Предоставление нового функционала, часто на стыке нескольких продуктов (например, автоматическое назначение или перенаправление заявок в ServiceDesk через почту)
  3. Предоставление другого интерфейса (например, мобильное приложение)

Методы разработки под Exchange были начиная с самой первой версии продукта. Они менялись, дорабатывались, изменялись и вымирали.

Основы разработки под Microsoft Exchange Server - 2

На сегодняшний день основные способы разработки ведутся с использованием EWS Exchange, REST API и других веб- и не веб-сервисов.

Про миграцию со старых способов разработки на более новые можно почитать тут.

А пока поговорим немного подробнее о каждом из них.

Разработка с помощью EWS

EWS Exchange и другие веб-сервисы позволяют получить доступ к данных почтового ящика в Exchange Online или в локальной версии Exchange, начиная с Exchange Server 2007. Предоставляют возможность создания пользовательских или серверных приложений с непосредственным доступом к пользовательским данным.

Таких технологий в данный момент несколько:

  • EWS, EWS Managed API и EWS Java API
  • Autodiscover POX/SOAP
  • REST APIs for Office 365
  • Unified Messaging (UM) (старый сервис, лучше использовать EWS Managed API)

EWS — это комплексная служба, которую приложения могут использовать для получения доступа практически ко всем данным, хранящимся в почтовом ящике локальной версии Exchange или Exchange Online в составе Office 365. Для обеспечения доступа к серверу Exchange Server служба EWS использует стандартные веб-протоколы. Такие библиотеки, как EWS Managed API, позволяют преобразовать операции EWS для предоставления объектно-ориентированного интерфейса.

Операции EWS можно вызвать из любой операционной системы и с помощью любого языка, потому что при обработке запросов и откликов EWS используется протокол SOAP. Важная составляющая кода — это XML-код, который используется для создания запросов EWS и возврата XML-откликов с сервера.

Теперь Managed API EWS доступен в виде проекта с открытым кодом на сайте GitHub.

С помощью библиотеки с открытым кодом вы можете:

  • добавлять исправления ошибок и улучшения в API;
  • получать исправления ошибок и улучшения до того, как они станут доступны в официальном выпуске;
  • получать доступ к самой полной и актуальной реализации API, которую можно использовать для справки или для создания новых библиотек на новых платформах.

На сайте Microsoft есть набор из 101 примера кода, чтобы можно было понять, как работает сервис и возможности программирования.

Служба Autodiscover предоставляет информацию о конфигурации, которую приложение использует для создания соединения с сервером Exchange. Вы можете использовать службу Autodiscover SOAP для отправки сообщений между клиентским приложением и сервером Exchange для определения параметров, которые приложение будет использовать для подключения к Exchange. Служба Autodiscover SOAP (в отличие от Autodiscover POX) предоставляет пакетные запросы настройки Autodiscover и более подробный контроль над тем, какие параметры возвращаются в ответ. Autodiscover SOAP более современная версия и рекомендуется использовать ее.

REST API (API почты, календарей и контактов) упрощают программирование на Exchange, предоставляя знакомый синтаксис, разработанный с открытым доступом (например, поддержка открытых стандартов JSON, OAUTH, ODATA) и гибкость (например, гранулированный доступ к данным пользователя). Эти API-интерфейсы позволяют разработчикам подключаться с любой платформы, будь то веб-сайт, ПК или мобильный клиент. SDK существуют для .NET, iOS, Android, NodeJS, Ruby, Python, Cordova и CORS для использования в одностраничных веб-приложениях JavaScript.

Это дает следующие преимущества:

  • Поскольку эти API требуют OAuth для аутентификации, ваше приложение не должно обрабатывать или хранить учетные данные пользователя.
  • OAuth позволяет запрашивать разрешенным пользователем только определенные данные. Например, вы можете создать свое приложение для запроса чтения только календаря пользователя.

Более подробно с разработкой с помощью веб-сервисов можно ознакомиться по ссылке.

Разработка без использования веб-служб Exchange

Разработку без использования веб-сервисов или с минимальным использованием можно разделить на несколько направлений:

  • Кастомные транспортные агенты, которые расширяют встроенный функционал (например, пересылка всех сообщений в другую организацию для внутренних пользователей перед отправкой или отправка сообщений, опираясь на домен отправителя)
  • Программы или интерфейсы, использующие Powershell (например, программа для ServiceDesk с определенными скриптами или интерфейс для хостинга Exchange)
  • Мобильные клиенты или приложения, использующие ActiveSync
  • Утилиты Enterprise уровня (резервное копирование, антиспамантивирус, миграции)
  • Утилиты более узкого назначения (низкого уровня, например, на CC++)

Вы реализуете транспортные агенты, которые регистрируются на события, а затем предпринимаются действия, когда это событие срабатывает. Каждый из трех типов агентов (SmtpReceiveAgent, RoutingAgent, DeliveryAgent) может регистрироваться для разного набора событий.

На следующем рисунке показано, где в транспортном конвейере транспортные агенты могут регистрироваться на события.

Основы разработки под Microsoft Exchange Server - 3

Когда сообщение входит в транспортный конвейер, агент транспорта, полученный из класса SmtpReceiveAgent, может воздействовать на сообщение во время любого из событий SMTP, для которых зарегистрирован агент. Агент, полученный из класса RoutingAgent, может действовать на любом из четырех событий классификатора, для которых он зарегистрировался. Агент, полученный из класса DeliveryAgent, может воздействовать на сообщение во время любого из событий доставки, на которые он зарегистрировался.

Exchange Management Shell предоставляет богатый набор команд на платформе Windows PowerShell для управления Exchange Online или локальную версию Exchange, начиная с Exchange 2013. Вы можете использовать Exchange Management Shell для создания двух видов инструментов: сценарии командной строки, которые работают в среде Windows PowerShell, и инструменты, которые используют командлеты Exchange Management Shell через управляемый интерфейс. Вы можете использовать управляемые приложения для создания стандартного пользовательского интерфейса Windows или веб-интерфейса для администрирования сервера Exchange.

Как пример такого приложения можно посмотреть GUI интерфейс для миграции данных в облако по ссылке.

Протокол Exchange ActiveSync предназначен для прямой синхронизации мобильных устройств с Exchange, включая легкие клиенты, такие как приложение Windows 8 Mail и Calendar, которое может использоваться в мобильных сценариях. Exchange ActiveSync оптимизирован для приложений с низкой пропускной способностью, таких как приложения для обмена сообщениями, которые выполняются на мобильных устройствах. Усовершенствования протокола Exchange ActiveSync в первую очередь поддерживают стабильность и надежность для сценариев мобильных устройств. ActiveSync открытый протокол, более подробную информацию о нем можно посмотреть по ссылке.

Если зайти на google play и набрать в поиске Exchange activesync, то мы получим более 100 результатов приложений, написанных для Exchange, использующих activesync.
Несмотря на то, что почти каждый телефон имеет встроенную поддержку AS, большинство заказчиков хочет расширить его функциональность такими вещами, как двухфакторная аутентификация, контейнеры и т.д.

Для крупных фирм важно иметь высокую доступность данных, организованность процессов и возможность точного планирования. В связи с этим на рынке ПО есть огромное количество приложений, обеспечивающий подобный функционал. По направлениям, например, утилит архивирования почты более сотни, можно посмотреть информацию о самых крупных компаниях на странице Magic Quadrant for Enterprise Information Archiving.

При этом для каждого ПО выбираются свои языки программирования и способы реализации. Компании могут использовать множество предоставленных возможностей для составления архитектуры и принципов работы приложений. Например, для утилит резервного копирования и восстановления есть раздел на MSDN, описывающий подробно все процессы по ссылке.

Также для многих служб и процессов существуют дополнительные API для написания программ на СС++ для более узконаправленных запросов и программ. Например, для ESE можно посмотреть по ссылке.

Программировать или не программировать решать каждой компании самой, но стоит признать, что Exchange имеет огромные возможности для расширения функционала и предоставляет все средства для этого.

Об авторе

Михаил Сартаев — системный архитектор в группе компаний АйТи. Является действующим MVP по направлению Office Servers and Services. Занимается внедрением решений для объединенных коммуникаций. Статьи Михаила вы также можете прочитать в блоге на wordpress.

Автор: sahsAGU

Источник

Поделиться

* - обязательные к заполнению поля