В 2017 году компания Зетта Страхование приняла решение отказаться от Microsoft SharePoint в пользу Битрикс24. Зачем, почему и как — под катом.

Среди предпосылок были:

• высокая стоимость владения MS SharePoint в сравнении с доступной моделью лицензирования Битрикс24;
• мультифункциональность Битрикс24;
• общий тренд к импортозамещению (но это не точно).

Сроки были весьма сжатыми, а SharePoint (SP) был брендирован. Он включал в себя пару кастомных доработок и содержал гигабайты данных, которые ни в коем случае не должны были потеряться при переезде:

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

Новый портал на Битрикс24 задумывался брендированным, интегрированным с AD с настроенным SSO и удобным для пользователей. В идеале пользователи вообще не должны были ощутить эффект от перехода.

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

Чтобы продать что-нибудь ненужное, нужно сначала купить что-нибудь ненужное. (с) Дядя Фёдор

Первым делом для миграции нужно получить выгрузку данных с SharePoint в удобоваримом формате. Часть информации (новости, данные пользователей, метаданные файлов) мы просто забрали из БД SP в виде XML. Сложнее пришлось с файлами — их выгрузили в отдельный архив, а в упомянутый выше XML, кроме метаданных, записывали путь к файлу от корня архива. Однако, контент страниц портала таким образом забрать не удалось: мало того, что информация размазана на десятки сайтов, она еще и хранится в таблицах в непригодном виде, со сниппетами в формате SP.

Для переноса контента страниц мы отважились на парсинг боевого портала, собирая с них сформированный HTML — такой путь показался оптимальным. Для этого взяли crawler, и в первый же день столкнулись с проблемой: он не принимает символ @ в NTLM авторизации (пришлось просить заказчика сменить пароль для учетной записи). Дальше дело за малым — определяем точки входа, исключения (чтобы не собирать лишнее, например профили пользователей) и контентную область (нет смысла парсить всю страницу, так как в Битрикс24 свой шаблон с хедером и футером). Содержимое области сохранялось в PHP файл с тем же именем и адресом относительно корня сайта, что упрощало работу по восстановлению работоспособности ссылок между страницами и давало возможность пользоваться штатным визуальным редактором в Битрикс24. В полученном контенте встречались вызовы файлового менеджера SP (заменили на вызов компонента для вывода соответствующей папки Диска Битрикс24), вызов Flash player (заменили средствами HTML5) и многочисленные ссылки на другие страницы (приводили к виду относительно корня сайта, убирая из ссылки доменное имя).

AD: магия из коробки или чистилище интегратора?

Выгрузка готова и отдана на согласование заказчику, а мы тем временем переходим к самой миграции. Начнем с пользователей, которые изначально создаются из Active Directory, а после обогащаются данными из SP посредством заготовленной XML.



Среди заказчиков и молодых интеграторов — всех, кто не сталкивался на практике с интеграцией Битрикс24 с AD, принято считать, что это из коробки. Все так, если коробкой называть ящик Пандоры. Дело совсем не в том, что это связка технологий, работающих на разных платформах — Linux и Windows. И не в понимании работы samba, без которого шаг в сторону от штатного мастера настройки равносилен шагу в топкое болото. И даже не в тех двух неделях, за которые реально наладить сетевое взаимодействие (во время последней интеграции наши сисадмины порвали бубен).

Уже когда были настроены соответствия полей и забрали пользователей, вскрылась проблема со структурой компании. У заказчика были отделы с одинаковыми названиями, находящиеся в различных филиалах компании. Битрикс24 считал, что это один и тот же отдел и объединял их. Из предложенных вариантов решения (модификация ядра Битрикс24, модификация передаваемых данных “на лету”, модификация структуры в AD под требования Битрикс24) в этот раз был выбран самый правильный, что позволило поставить в этом вопросе точку.

Дерево разделов

Следующий шаг — перенос данных страниц департаментов и файлов. С помощью парсера мы подготовили дерево разделов и страниц, соответствующее путям на SharePoint. Ввиду обнаруженных конфликтов с некоторыми служебными разделами Битрикс24, мы разместили его в разделе /content/, а чтобы все внутренние ссылки заработали, организовали редирект для apache:

RewriteRule ^(.*)\.aspx$ /content$1\.php [R=301,L]

Файлы после выгрузки у нас также размещены древовидно и находятся в многогигабайтном архиве, который мы распакуем в /upload/sp/. “Оживит” их пробежка скриптом с добавлением на Диск (для нужных разделов) и правило nginx для существующих ссылок:

location ~* \.(doc|docx|jpeg|jpg|pdf|png|ppt|pptx|rar|txt|xls|xlsx|zip)$ {
try_files $uri /upload/files$uri = 404;
}

Про браваду, брендирование и бюджет

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


Нам было по душе отказаться от мартышкиного труда и сэкономить бюджет заказчика: мы ограничились цветовой гаммой и добавлением нескольких элементов вроде слайдера и кастомного меню. Эконом-вариант с сохранением возможностей обновлений. Кстати, вышло вполне достойно. Для новостей сделали отдельный шаблон, адаптируя верстку оригинала.

Вместо эпилога

Для закрытия задачи оставалось еще несколько штрихов вроде настройки меню и прочей косметики, настройки кластерной архитектуры для обеспечения отказоустойчивости, однако про это уже не сегодня. А сегодня мы хотели отдать хвалу инженерам русским, и на живом примере в очередной раз показать, что возможно всё. Не так страшен волк, если в лесу не первый раз, да и с Михалычем на уазике едешь.

Всем хороших интеграций!