Немного о Marvel и его прошлом

Компания «Марвел-Дистрибуция» является официальным дистрибьютором серверного оборудования производителей Hewlett Packard Enterprise и Lenovo. Основанная в 1991 году «Марвел-Дистрибуция» на сегодняшний день является одним из крупнейших широкопрофильных IT-дистрибьюторов на территории России и стран СНГ.

На момент обращения в ИНТЕРВОЛГУ у компании уже был сайт, построенный на базе React. Сайт был быстрый и отзывчивый, но обладал одним существенным недостатком для интернет-магазина – не индексировался поисковыми системами.

Новые горизонты для Marvel

Наша задача была в кратчайшие сроки переехать на Битрикс, сделав при этом 3 сайта:

• c каталогом продукции Hewlett Packard Enterprise;

• c каталогом продукции Lenovo;

• c общим каталогом.

1С-Б: Управление сайтом – хорош для интернет-магазинов, т.к. имеет много полезных возможностей из коробки. Т.к. сроки были сжаты, мы предложили заказчику ускорить задачу, воспользовавшись тиражным решением. Выбор пал на решение от Аспро – «Аспро: Next - интернет-магазин».

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

Изюминка проекта — источник данных. Предыдущая версия сайта тянула данные из самописной учетной системы (УС) в режиме реального времени. Логика работы, все стандартные компоненты и возможности системы предполагают хранение данных в БД сайта. Поэтому запрос данных в режиме реального времени не подходил.

Нужно было реализовать обмен данными в фоновом режиме. Все данные мы логически разбили на сущности. Например, данные о городах, с которыми работает сайт, относятся к сущности «Города». Кстати о городах, их также пришлось загружать из УС, поэтому довольно мощная система местоположений осталась в стороне. Еще одной сущностью обмена являются поставщики. И с ними связана, пожалуй, самая серьезная доработка публичной части сайта – реализовать ограничения платежных систем и служб доставки от поставщиков.

Фундамент нового Marvel

Итак, основной задачей было реализовать обмен с учетной системой заказчика. Для получения данных УС имеет закрытое Rest API.

Обмен предполагает импорт:

• городов;

• поставщиков;

• каталога (разделы, свойства, товары с ценами);

а также экспорт:

• заказов;

• данных формы «Задать вопрос».

Структура данных, естественно, отличается от Битриксовой, поэтому при обмене требуется конвертация данных. Города и поставщики хранятся в Highload-блоках, форма «Задать вопрос» – веб-форма, остальные – в одноименных сущностях системе.

Типы обмена

Импорт сущностей мы разделили логически на первичный и повторный. При первичном импорте сущности ее данные на сайте отсутствуют. Все элементы сущности будут выгружены на сайт. При повторном импорте – элементы, которых еще нет на сайте будут добавлены, а которых нет в ответе API – удалены.

Для элементов сайта мы храним хэш основных значимых полей. Это позволяет нам отслеживать изменения данных и не обновлять элементы в случае отсутствия изменений. Исходя из наличия хеша мы также разделяем импорт на «полный» и «только изменения».

Импорт разделов

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

• при первичном импорте на сайте создается полная копия дерева разделов.

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

Такой сценарий предполагает, что иерархия разделов на сайте может заметно отличаться от таковой в УС. Но все же импорт позволит получать и изменения с УС.

Расписание

Обмен с УС выполняется с помощью агентов по расписанию во время наименьшей активности посетителей на сайте. Обмен сущностей происходит в строго установленном порядке. Сначала импорт независимых сущностей «Города» и «Поставщики», далее – импорт сущностей каталога «Разделы», «Свойства», «Товары», и в конце – экспорт «Заказов». Обмен осуществляется поочередно для каждого сайта.

Управление и мониторинг

Мы также предусмотрели механизмы отслеживания и ручного управления обменом. Для этого был разработан гаджет для рабочего стола в админке.

Гаджет позволяет отслеживать текущий обмен:

• время начала и продолжительность;

• настройки;

• ошибки;

• текущий прогресс по сущностям.

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

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

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

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

Логирование

Основные данные об обмене, отображаемые в гаджете мы храним в отдельной таблице, а для логирования ошибок используем удобный инструмент «Журнал событий», куда пишем ошибки обращения к API, ошибки добавления элементов в БД сайта, ошибки экспорта заказов и прочее.

Гаджет имеет одну единственную настройку – ID сайта, с которым он работает. Соответственно, для каждого сайта – свой гаджет. При таком режиме гаджет занимает всю площадь экрана и позволяет отслеживать всю необходимую информацию на 1 экране.

Сложности и риски

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

С этой проблемой мы столкнулись при импорте свойств. Структура данных свойств сильно разнилась. Если для получения данных большинства сущностей нам хватало 1 запроса, то здесь потребовалось несколько. Эта особенность не была замечена на раннем этапе. Не было и возможности доработать API в рамках установленных сроков. Пришлось мириться с тем, что есть. Как результат – немного увеличилось время на реализацию импорта свойств, а также сам импорт свойств выполняется дольше, чем могло быть.

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

В целом – это не существенно, т.к. обмен все равно происходит в фоновом режиме в момент наименьшей пользовательской активности.

Заключение

Описанный проект – один из немногих, где недостаточно простого умения разрабатывать сайты. В подобных проектах мы всегда уделяем время предпроектной аналитике, построению архитектуры системы, проектированию структуры данных.

Мы работаем со сложными веб-системами и не боимся трудных задач. Задачи интеграции – наша специализация, какими бы сложными они не были.