Корпоративный портал строительного девелопера «Первый домостроительный комбинат»

Особенности реализации проекта

У такой крупной девелоперской компании очень размашистая организационная структура. Разные департаменты имеют разный уровень свободы в выборе решений. Так получилось и у ГК ФСК – как минимум три разных корпоративных портала использовались дочерними компаниями к тому моменту, как мы подключились к проекту.

Перед нами была поставлена задача объединения информационных потоков между разными экземплярами Битрикс24. Сотрудники компании должны воспринимать группу как единое целое, поэтому и публикации, новости, мероприятия, социальная активность должны быть централизованы, несмотря на разные IT системы. 

У ГК ФСК был уже централизованный источник данных. Нашей целью была синхронизация с этим источником данных, но с учётом локальной специфики компании «Первый ДСК».

Эта задача сопряжена с тем, что «Первый ДСК» только начал внедрять Битрикс24 в свою IT инфраструктуру, соответственно мы принимали участие и в первичной настройке системы, и помогали в интеграции с 1С ЗУП, и с их ActiveDirectory сервером. 

Выполненные работы

Развёртывание Битрикс24

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

Все эти вопросы были успешно решены между нашими системными администраторами и администраторами заказчика. 

Интеграция с типовыми системами заказчика

AD, NTLM, 1C:ЗУП

Есть ряд подсистем, которые часто используются клиентами в своих внутренних сервисах. Одна из них – LDAP и Active Directory серверы. Для Битрикс24 – это типовая интеграция, которая позволила частично решить вопрос с синхронизацией всех сотрудников строительной компании в портал «Первый ДСК». Вместе с этим, благодаря встроенным возможностям Битрикс24, у этих пользователей появляется возможность использовать NTLM аутентификацию с помощью своего рабочего ПК. 

Вторая часть организационной структуры была подгружена из 1С:ЗУП также путём стандартной интеграции с незначительными доработками. 

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

Информационный обмен

Подавляющую часть времени мы работали над проблемой информационного обмена между порталами группы компаний. 

Со стороны IT-службы заказчика был предложен механизм двухсторонней синхронизации, который предоставлял инструменты как для получения сведений из других порталов группы компаний, так и позволял отправить туда часть сведений. 

Получив задание от заказчика мы его детально изучили и сделали вывод, что оно имеет ряд недостатков, требующих устранения. IT служба заказчика согласилась с нашими доводами и мы совместно с ними доработали протокол обмена информацией, чтобы всем участникам процесса было комфортнее работать с данными. Это улучшение позволило сэкономить, по нашим оценкам, около 20% трудозатрат на реализацию функции синхронизации. 

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

Основной сущностью обмена являлись Кросспортальные Новости. Эта сущность жила по определённому бизнес-сценарию. Краткие тезисы:

• есть Глобальные новости, которые должны быть доступны сразу всем порталам
• есть локальные новости, которые доступны только на том портале, на котором они опубликованы
• новость можно сделать глобальной или локальной независимо от того, на каком из порталов она отображена
• только определённый круг лиц мог выполнять операции по глобальной публикации
• если новость изменилась, то эти изменения должны рассылаться на все порталы с уведомлениями
• каждая новость содержит связанную информацию – лайки, просмотры, комментарии, авторство, которые тоже должны рассылаться между порталами
• общение в комментариях, просмотры и лайки должны быть “сквозными” между всеми порталами
• система должна продолжать работать в условиях, когда потерялась сетевая связанность между порталами

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

При построении подобных приложений мы часто используем не только встроенные инструменты в Битрикс 24, но и признанные в мировом сообществе инструменты и библиотеки. 

Например, для реализации логирования мы использовали библиотеку monolog, которая позволила нам принести в проект абстракцию над логированием. Эта абстракция позволила нам работать с логами в разных окружениях по разному. В режиме разработки – отправлять логи в файловую систему разработчика, а в режиме реальной эксплуатации – в централизованную систему сбора логов заказчика. 

Для реализации клиентского http слоя мы использовали Guzzle, что позволило эффективно использовать кеширование, а также провязать наш слой логирования с ним. Это даёт возможность очень подробного анализа всех коммуникаций между серверами во всех окружениях.