Как мы автоматизировали загрузку товаров на онлайн-витрину Fix Price
Всем привет! Меня зовут Дмитрий Ермошкин, и я системный аналитик компании Fix Price. Расскажу сегодня о том, каким образом нам удалось автоматизировать загрузку товаров на онлайн-витрину компании.
У нас было несколько систем, в которых мы хранили данные для дальнейшей публикации на витрину: SAP, LCB (склад), 1C. Предложения о новых товарах поступали из разных каналов: email, мессенджеры, а менеджеры занимались проверкой данных, уточняли данные у поставщиков. Однако у Fix Price несколько сотен поставщиков и несколько тысяч товаров, а автоматическая проверка полноты данных при такой схеме затруднена. Поэтому была поставлена следующая задача: приведение данных к качественному виду и их консолидация в единой системе. При этом система должна быть отказоустойчивой и производительной, а также должно быть обеспечено удобство работы с ней для поставщиков.
Как всё работает
Бэкендом в новой системе служит Pimcore, которая выступила в качестве эталона и основной базы данных. Именно в Pimcore хранится полная и точная информация обо всей продукции сети Fix Price и именно в Pimcore поступают данные, вводимые через личный кабинет (ЛК) в веб-приложении.
Связующим звеном в единой системе служит сервисная шина ESB. ESB — «сердце» всей схемы, она обеспечивает обмен сообщениями между остальными системами и позволяет быстро перестраивать интеграции, не затрачивая много ресурсов со стороны команды разработчиков.
В качестве посредника используется RabbitMQ — брокер сообщений, необходимый для повышения отказоустойчивости и увеличения производительности системы.
Для анализа и визуализации данных и ИТ-мониторинга используется Grafana.
Облачное хранилище S3 задействуется для бэкапа данных Pimcore и витрины.
Почему мы выбрали именно такое ПО
Здесь расскажу о ключевых для нас преимуществах двух самых важных элементов системы.
Pimcore
Главное требование к технологии — это должно было быть «коробочное» опенсорс решение, достаточно гибкое для построения логики внутри системы под наши бизнес-задачи. То есть то, что мы сможем с легкостью масштабировать, поддерживать и кастомизировать в зависимости от изменений бизнеса. Выбирали из двух технологий PIM/MDM систем, Akeneo и PimCore, так как эти опенсорс решения мы могли развернуть внутри нашего контура, что, на наш взгляд, выгоднее, чем облачное решение по подписке.
В ходе сбора требований мы пришли к выводу, что нам необходима не классическая PIM, а скорее MDM-система, где мы в будущем сможем управлять не только данными по товарным позициям, но и маркетинговыми представлениями товаров и данными о пользователях. Также важно иметь возможность отслеживать популярность товаров, создавать отдельные группы сущностей под акции, временные события, управлять ценами и т.д. PimCore в бесплатном варианте обладает перечисленным выше функционалом, а вот в Akeneo это входит только в решение Enterprise.
На этапе формирования MVP для нас было важно не просто внедрить новую технологию, а сделать с ее помощью процесс работы с товаром более удобным и понятным. Дело в том, что в нашей системе взаимодействуют сразу несколько департаментов со своими ролями, определенными требованиями и ограничениями. Поэтому нам требовалось создать сложную и в то же время гибкую иерархию разных категорий товаров, которые смогут наследовать свойства друг друга в определенных случаях и которые мы сможем постоянно изменять, контролировать и масштабировать. При этом нужно было предусмотреть и правила валидации для карточек, чтобы обеспечить качество данных на каждом этапе. В этих моментах мы также склонялись в сторону PimCore — эта система показалась нам очень гибкой, в отличие от стандартных правил и иерархии Akeneo.
Пользовательский путь должен распространятся на работу с файлами, поэтому нам требовался Digital Asset Management для работы с файлами, фотографиями, сертификатами, инструкциями. Для файлов требовалось задавать собственные атрибуты и ограничения: например, разные страны действия сертификатов, разные статусы фотографий товаров и т.д. И здесь также выигрывал PimCore: гибкость настройки workflow и индивидуальных параметров подходила под наши бизнес-задачи, в отличие от стандартных механизмов Akeneo, где сделать пользовательский путь с уникальными условиями намного сложнее. Причем даже в версии Enterprise.
ESB
При проектировании интеграций мы учитывали, что есть система-источник и несколько систем-потребителей. Поэтому у нас были особые требования к тому, как выстраивать интеграции. Мы хотели реализовать их таким образом, чтобы интеграции были выполнены не по схеме «точка-точка», а через единое место, которое мы можем контролировать, масштабировать и быстро изменять в случае, если интеграции будут меняться, либо будут добавляться новые системы.
Писать еще один большой сервис со всей логикой, на поддержку которого требуется постоянно привлекать, а иногда и в постоянном режиме содержать целую команду — не вариант. Поэтому мы стали смотреть в сторону Enterprise Service Bus, единое место для построения всех интеграций, со своим логированием и, что немаловажно для нас, с готовыми коннекторами для большинства интеграций, которые нам требовались.
При сравнении скорости внедрения самописного решения и сервисной шины мы выбрали последнюю. Мы подсчитали, что на внедрении ESB нам удастся сэкономить 3–4 месяца, поскольку большинство коннекторов там уже есть «из коробки».
ESB также закрывала и еще несколько наших потребностей. Например, при построении интеграции без промежуточного звена порой возникают ошибки, и для того чтобы найти и исправить ошибку, часто приходится проверять все участвующие в интеграции системы. Также при масштабировании необходимо собирать все команды, ответственные за другие системы, и тестировать интеграции заново. ESB же позволяет нам контролировать все интеграции из центральной точки.
При изменении набора полей, типа этих полей, обогащения данных мы добавляем их все в ESB, причем для каждой интеграции отдельно. Все исходящие и входящие потоки мы логируем также в одном месте. Поэтому, если где-то возникает ошибка, мы сразу видим это на графиках и понимаем, на чьей стороне она возникла.
ESB мы выбрали еще и потому, что это LowCode/NoCode платформа, которая имеет собственный графический интерфейс. Внедрение данной технологии позволило нам контролировать интеграции, а также добавлять новые, не привлекая команду разработки. Для этого достаточно было обучить нашего системного аналитика добавлять и настраивать коннекторы под изменяющиеся требования. Конечно, мы продолжаем подключать разработчиков, но только на реально сложные задачи: например, для написания собственного коннектора, когда стандартный нам не подходит.
Чего мы добились
Благодаря внедрению сервисной шины нам удалось реализовать сразу несколько возможностей:
загрузка в едином канале, через веб-приложение;
автоматизация проверки полноты данных перед их загрузкой на витрину;
использование разных классов и шаблонов для разных товарных групп;
возможность изменения структуры карточек «на лету»;
возможность массового предложения карточек товаров через личный кабинет поставщика и массовой обработки предложений через систему PimCore.
Это позволило нам значительно упростить работу с карточками товаров, увеличить скорость загрузки и повысить надежность хранения данных. А кроме того, мы облегчили работу сразу нескольким департаментам FixPrice, освободив специалистов от рутины для решения более важных задач.
Буду рад ответить на вопросы!
