Рано или поздно успешный проект будет нуждаться масштабировании и расширении ИТ-архитектуры. Что делать, если все начиналось с обычного сайта, а сейчас выросло до масштабов интернет-магазина в Европе и сайта с дистрибьюторской сетью в России?
Наш тимлид Паша рассказал о том, как вести европейский проект с русскими корнями и 2 сайтами с разными базами данных, разной CMS и вообще всем.
Предыстория: сайты мультиязычные (весь контент представлен на 5 языках), были разнесены по разным доменам, имели различные cms в управлении (bitrix, wordpress), любые изменения вносились в нескольких репозиториях.
Кроме того, заказы хранились в разных CMS, сбор аналитики трудозатратен.
Иными словами, администрирование и сбор данных — страшный сон контент-менеджера и аналитика.
Для управления учетом номенклатуры используется 1С «Комплексная автоматизация» с кастомной структурой хранения данных для поддержки мультиязычности.
Наша ключевая цель: объединить все управление в единой cms Bitrix для удобного управления и передачи данных, разработать удобный ЛК для европейского сайта.
Задачи, которые выделили в ходе проекта:
Начать мы решили с одной из главных и первостепенных задач — разработать структуру репозиториев. Поскольку в проекте несколько сайтов, для более комфортной работы и организации порядка в работе с файлами сайтов, было принято решение разделить основные папки сайтов на разные репозитории. Также такое решение позволит (если это будет необходимо) разделить сайты на разные сервера. Структура git-репозиториев выглядит так:
Каждый дополнительный репозиторий подключается как git submodule.
Для работоспособности битрикса директории bitrix, local, upload к репозиториям подключаются через символические ссылки на сервере.
Настройка домена и указание пути до нужного submodule происходит в конфигурации nginx.
Такое решение позволило иметь нужные компоненты, шаблоны компонентов и классы для работы логики бекенда в одном экземпляре (только в одном репозитории).
Для корректного отображения информации о товаре: характеристика, описание, остатки и тд необходимо реализовать импорт данных из 1С.
Компания сосредоточена на европейском рынке, контент на сайтах представлен разными наборами языков для отдельно взятых доменов. Такое решение накладывает ограничения на хранение данных, в связи с чем стало невозможно использовать стандартное решение импорта данных из 1С в битрикс.
Решений для нестандартных данных можно было выбрать несколько:
1. Написать собственный импорт, исходя из требований;
2. Доработать данные под стандартный импорт битрикса.
Так как со стороны 1С не было написано никакого нового функционала для обмена между 1С и сайтом, а отличие было только в структуре хранимых данных (вместо конкретных значений 1С хранит XML-структуру данных), было принято решение использовать стандартный функционал импорта битрикса из 1С.
Для такого решения была написана обертка, которая отслеживает начало импорта, пересобирает файлы импорта под необходимую структуру и отдает на обработку битриксу.
Стандартная реализация битрикса имеет различные события, вызываемые в разные моменты импорта, основная идея — подписка на такие события и изменение файлов, получаемых от 1С.
Так как на проекте используется несколько 1С и импорты различные, то появилась необходимость определять, какой именно импорт производится.
Для этого входная точка импорта была заменена на нашу, вместо битриксовой. Ключевым событием является OnBeforeCatalogImport1C, на котором проверяются файлы, получаемые от 1С, и пересобираются в нужной структуре, которая требуется стандартному импорту 1С.
Для сохранения мультиязычности данные в 1С хранятся в виде xml дерева и приходят к нам в таком же виде. В событии мы читаем такие данные, вытаскиваем нужные данные по каждому языку и создаем новые файлы - отдельные под каждый язык. То есть получаем от 1С один файл, а в битрикс передаем столько, сколько языков получили.
Импорт битрикса цикличен и завязан на шагах, для того чтобы система обработала все наши файлы необходимо сообщать о каждом файле по отдельности, для этого на событии OnSuccessCatalogImport1C подменяются шаги (этапы), если есть еще не обработанные файлы, то цикл запускается с начала, но уже с новым файлом.
Пример структуры того, что получаем от 1С. Битрикс в импорте ожидает строку с конкретным значением, например, товар «Индейка с Уткой» для щенков. От 1С же мы получаем такие фразы на всех языках, которые должны быть на сайте, поэтому и формируем отдельные файлы. один язык - один файл - один информационный блок.
Благодаря такому подходу не пришлось реализовывать собственную логику с созданием информационных блоков, свойств, настроек разделов и элементов. Что позволило нам существенно сократить сроки реализации проекта и бюджет клиента на разработку.
Из минусов можно отметить недостаточную документацию Битрикса по структуре файлов импорта — описана лишь малая часть из того, что импорт позволяет делать.
Все эти решения мы объединим в один блок, т.к. они были весьма стандартными и просто решали задачи клиента.
Из «коробки» Битрикс предоставляет компоненты для реализации как самого каталога, так и корзины. Но такое решение не подходит по ряду причин — тяжелые и не нужные процессы внутри компонентов, неполная документация у ряда компонентов.
В связи с этим был реализован каталог на основе классов Bitrix D7.
Для совершения платежей и завершения этапа оформления заказа был проинтегрирован сервис mollie.com. Сервис предоставляет полный спектр услуг по обработке платежей - различные способы оплаты, выставление счетов, различная документация, необходимая для юрлиц.
Для интеграции платежной системы с Битриксом была использована стандартная возможность - наследование от общего класса ServiceHandler и интеграция с API Mollie.
На сайте для пользователей есть несколько сценариев для работы с смс-кодами.
Ключевые — регистрация, смена/восстановление пароля, удаление аккаунта.
Стандартные интеграции Битрикса с смс-провайдерами не имеют возможности отправки на европейские номера, в связи с этим возникла необходимость интеграции со сторонним сервисом.
И всё бы ничего, задача и правда легкая, но в текущих реалиях (всем известные санкции) сервисов, работающих с европейскими номерами крайне мало.
Первоначально для интеграции был выбран сервис unisender, гарантирующий доставку смс на европейские номера. В ходе интеграции с их api и тестировании были проблемы с тех. поддержкой.
Заказчик оформил реальные номера в Бельгии и Испании. Через e-sim мы смогли настроить номера телефонов себе и протестировать отправку — в конечном итоге сервис сообщил, что не только не гарантирует отправку смс на европейские номера, но и вовсе не будет работать с ними.
На данный момент мы в поиске новых решений.
На старом сайте ключевой проблемой карты является невозможность поиска магазинов по названию. В новой реализации карта предоставляет возможность поиска как по физическим адресам на карте, так и по названиям торговых точек.
Точки на карте хранятся в Битриксе в информационном блоке, имеют набор характеристик, в частности — название магазина, полный адрес, координаты для Яндекс.Карт, координаты для Google Maps.
При загрузке страницы асинхронно на карту подгружаются все магазины в json формате.
Поиск по точкам на карте происходит по названию магазина, адресу торговой точки.
В результатах поиска для найденных результатов на яндекс карте, как в нативном поиске, так и в поиске по json выводятся расстояния до найденных торговых точек (10м, 1213км и тп).
Для Google Maps расстояния выводятся только при поиске по json. Нативный вариант поиска не подразумевает расчет расстояния изначально, для этого необходимы дополнительные запросы к api Google Maps, что увеличивает количество запросов и стоимость обслуживания такого поиска.
В РФ продажа реализована через дистрибьюторскую сеть, а в Европе реализована собственная логистика и склады продукции, поэтому ЛК был необходим только для европейского рынка.
В личном кабинете пользователю доступно редактирование профиля (имя, телефон, почта).
Авторизация доступна через Google-аккаунт.
Для корзины и заказов реализовано хранение профилей доставки и получателей.
Пользователь может создать для себя различные адреса доставки, указав полный адрес и при последующих заказах выбирать такой адрес.
Может добавить себе профиль доставки — имя и телефон, по которому будет производиться доставка и получение. В ходе разработки проекта появилась необходимость ускорить задачи по фронтенду, было принято решение подключить 2 наших фронтенд-разработчиков. Фронт работ: страницы ЛК (профиль, заказы, профили доставки, изменение пароля, различные попапы и ui элементы сайта); реализация функционала карт (поиск по json + нативный поиск).
В результате клиент получил мультиязычные сайты под одним управлением на Bitrix и возможностью получать аналитику и любые данные по заказам в единой cms.
По факту, за время работы мы решили не только проблему с единой cms, но и: