Российский бизнес активно занимается импортозамещением ИТ. В этих условиях компаниям требуется непрерывность бизнес-процессов при переезде на новый стек. Особое внимание в этом процессе уделяется инструментам для коммуникации и планирования. 

Меня зовут Леонид Мотовских. Я руководитель команды Календаря VK WorkSpace. В этой статье расскажу о методах миграции календаря из MS Exchange в VK WorkSpace, как мы реализуем их под капотом и какие механизмы применяем для исключения конфликтов.

Варианты миграции календаря

Microsoft Exchange и предоставляемые в его экосистеме сервисы де-факто стали стандартом среди инструментов для корпоративной коммуникации. Поэтому при замене MS Exchange бизнес сталкивается с необходимостью мигрировать и дополнительные сервисы, такие как календарь.

В VK WorkSpace поддерживается миграция календаря из трех версий MS Exchange: 13, 16 и 19. Мы предлагаем два сценария переноса данных: миграция и подписка.

Теперь подробнее о каждом из них.

Миграция

Миграция — это односторонний «исход» событий календаря из MS Exchange в VK WorkSpace. Выполняется по следующему принципу:

• с помощью bash-скрипта sync_all.sh передаем email-адреса пользователей, календари которых требуется мигрировать;

• самописный сервис Exodus (исход) получает перечень email-адресов и делает запрос к EWS, Exchange Web Services;

• EWS отдает события календаря;

• события календаря через calendarpi-internal заводятся в Календарь VK WorkSpace.

То есть все просто: сходили в Exchange, забрали нужные данные, положили их в VK WorkSpace. События сразу отображаются в Календаре VK WorkSpace.

После переезда календари в MS Exchange и в VK WorkSpace продолжают работать независимо. Новые встречи в VK WorkSpace не будут отображаться в MS Exchange, и наоборот.

Подписка

Подписка — двусторонний вариант синхронизации, который предполагает передачу событий как из MS Exchange в VK WorkSpace, так и наоборот. То есть сценарий подписки реализует двустороннюю синхронизацию.

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

Сценарий подписки реализован сложнее сценария миграции — как минимум из-за особенностей работы с MS Exchange:

• Календарь MS Exchange может выдавать баги, которые нужно учитывать на своей стороне. Об известных багах пишут в официальной документации:

• В Календаре MS Exchange используются два идентификатора встреч, но нет ни одного способа сопоставить один с другим. Поэтому в некоторых случаях нам приходится буквально перебирать все идентификаторы встреч и мэтчить их между собой. 

• Повторяющиеся события в ответах MS Exchange по умолчанию возвращаются без повторений, только как «мастер-встреча». Чтобы увидеть сетку календаря с заполненными повторениями, требуется передать специальный флаг «показывать виртуальные встречи». Но пользоваться этим функционалом в полной мере невозможно: если включить отображение «виртуальных» встреч, часть других методов становится недоступна и возвращает 500.

И это лишь часть нюансов, которые мы учитываем.

Для работы двухсторонней синхронизации мы используем два самописных сервиса:

• Calendar Exchange Synchronizer, он же cexsy (да-да, «посмотри логи секси», «скиньте секси-логи») для импорта событий из VK WorkSpace в Exchange;

• Gobi — брат-близнец cexsy для импорта из Exchange в VK WorkSpace.

Точкой входа опять же служит bash-скрипт.

Теперь детальнее:

1. Через bash-скрипт subscribe.sh в Exodus передается информация о пользователях, календари которых подписываются на изменения.

2. Exodus сохраняет этих пользователей в базе данных, подготавливая их к подписке на MS Exchange.

3. Microsoft Exchange по коллбэку уведомляет Gobi о произошедших изменениях (создание встреч, изменение описания, времени).

4. Gobi из уведомлений собирает идентификаторы измененных встреч и обращается в Exchange, чтобы получить полную информацию о встречах, включая вложения и прикрепленные ссылки.

5. Gobi сохраняет маппинги встреч Exchange — VK WorkSpace в локальный Tarantool cexsy-tar или syncdb.

6. Полученная из Exchange информация отправляется по gRPC в VK WorkSpace, а вложения отправляются в облако.

Из VK WorkSpace в Exchange уведомления поступают похожим образом, только уведомления слушает Cexsy, а отправка уведомлений в EWS идет в формате XML, как этого требует MS.

Чуть больше конкретики

Подключение к Microsoft Exchange

Microsoft Exchange ограничивает доступ к календарям для третьих лиц. В официальной документации предлагается 4 способа получения доступа для миграции событий.

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

Синхронизация вложений

Сейчас вложения в событиях мигрируются только из MS Exchange в VK WorkSpace. Наоборот — нет.

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

Помимо этого, мы не поддерживаем синхронизацию Inline-вложений в Exchange, то есть файлов, не видимых получателю в списке вложений, но используемых внутри HTML-тела сообщения. Но мы уже прорабатываем механизмы для безопасного решения этих задач. Кроме того, у нас недавно появилась возможность пользователям публиковать занятость календаря в HTML формате.

Конфликты

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

Благодаря этому повторный вызов миграции через sync_all.sh не приведет к появлению дублей. Если встречу перенесли или переименовали, идентификаторы останутся без изменений, Gobi сопоставит встречи и перезапишет их новыми данными в VK WorkSpace. MS Exchange поддерживает подобный сценарий, поэтому Cexsy передает в него данные с настройкой AlwaysOverwrite.

Повторяющиеся события

И в MS Exchange, и в VK WorkSpace есть поддержка повторяющихся встреч с несколькими участниками. Например, создается встреча на группу пользователей каждый вторник в 12:00. Если изменить время и дату встречи, событие обновится у всех.

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

ICS от Microsoft Exchange

Exchange использует два инструмента уведомления о новых календарных событиях:

• пуш по коллбэку, о котором мы писали выше;

• ICS — стандартный текстовый формат файлов (с расширением .ics), используемый для обмена информацией о календарных событиях.

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

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

Краткое послесловие

Переезд из MS Exchange — непростая задача, с которой сталкиваются многие российские компании. Серебряной пули для ее решения нет: каждый клиент выставляет собственные требования к переезду.

Но мы предусмотрели несколько вариантов миграции событий в Календарь VK WorkSpace (хоть и временных), с помощью которых получается сидеть на двух стульях и после переехать в контур VK WorkSpace. 

Спасибо! С вами был Лёня, руководитель команды Календаря. Мы Календарь перевернем!