Привет! С вами Евгений Катасонов, product-менеджер, и Вадим Волков, лидер группы аналитики в СберТехе. В статье расскажем, как мы разработали Platform V Product 360 — решение по управлению продуктовым каталогом (PIM) ориентированное на рынок e-commerce и при этом закрывающее задачу управления банковскими продуктами
Архитектура и технологии
Не будем детально описывать архитектуру нашего приложения с перечислением всех компонентов. Вместо этого сосредоточимся на более высокоуровневом понимании логики работы нашего продукта. А именно — сервисы, их логика работы, взаимодействие между компонентами продукта.
Platform V Product 360 — это готовый инструмент для управления продуктовым каталогом, хранения маркетинговой информации, работы с карточками товаров и выгрузки данных в каналы продаж. Продукт более четырех лет успешно эксплуатируется в масштабах Сбера и позволяет автоматизировать ведение каталога различных банковских услуг.
В продукте пять ключевых компонентов— для простоты назовем их по основным функциям:
Каталог продуктов — основное хранилище данных для структурированного хранения и работы пользователей с продуктовыми карточками.
Модуль MDM — позволяет хранить и унифицировать большие данные в справочниках, которые невозможно хранить в рамках продуктовой модели карточек товаров.
Модуль интеграций — связывает данные PIM-системы с внешними источниками и потребителями данных.
Витрина — инструмент визуализации и представления продуктовых карточек потребителям при использовании API сервиса.
Web UI — графический интерфейс для пользователей системы, предоставляющий инструменты для эффективного управления данными о продуктовых карточках.
Мультитенантная архитектура
Для системы была выбрана мультитенантная архитектура, которая в нашем случае позволяет изолированно обслуживать разные отделы в организации в рамках одного продукта (сервиса).
Плюсы такой архитектуры:
Экономическая эффективность: одним сервисом могут пользоваться сразу несколько бизнес-подразделений одной компании, и не нужно развертывать дополнительные решения.
Эффект масштабируемости: возможность увеличить количество разных бизнес-подразделений организации, использующих продукт (сервис) без необходимости дополнительного развертывания продукта (сервиса).
Безопасность: можно разделять доступы и работать только с данными, которые относятся к конкретному бизнес-подразделению.
Бэкенд, или как нагрузки вас держат в тонусе
В PIM-системах бэкенд очень важен — от него зависит качество управления информацией о продуктах. Он не только обрабатывает данные, но и обеспечивает интеграции и обмен с базой данных для взаимодействия по API с фронтендом сервиса.
Мы создавали Product 360 в формате коробочного решения (on-premise), поэтому важно было понять, какими инструментами его можно будет развернуть. Остановились на двух форматах: Openshift и Kubernetes. Для хранения данных использовали PostgreSQL, язык разработки — Java.
Масштабируемость и производительность
Важно, чтобы система росла вместе с потребностями бизнеса. Меняется масштаб и количество клиентов — меняется и мощность ИТ-системы. Она должна обеспечивать работу с большим количеством запросов, потому что от производительности зависит эффективность работы пользователей с системой.
PIM-система должна быть отказоустойчивой и масштабируемой, особенно если речь о решении для компании, которая ведет крупные каталоги данных с множеством характеристик.
Оптимизация запросов и кеширование
При работе с ИТ-системой пользователь не хочет тратить время на поиски нужных данных. Важно хранить данные в специальном хранилище и точно знать, откуда система их берет при обращении. В PIM-системах кеширование используется для оперативного доступа к информации о хранимых продуктах. Если организация хранит миллионы товаров в каталоге, то кеширование позволяет мгновенно показать данные о товарах, не нагружая систему.
Преимущество кеширования — в скорости, производительности и удобстве. Пользователи получают информацию быстрей, и это улучшает их пользовательский опыт при работе с системой.
В Product360 была использована архитектура многоуровневого кэширования включая on-heap, off-heap и глобальный кэш. Такой подход обеспечивает масштабируемость и снижает нагрузку на базовые системы хранения данных. Небольшие часто используемые данные хранятся в быстром on-heap кэше, данные большего размера, например продуктовые карточки, перемещаются в off-heap. Глобальный кэш гарантирует доступность и согласованность информации для пользователей системы. В результате система становится более гибкой и готовой к обработке трафика и интеграции с цифровыми платформами.
Пользовательский интерфейс во благо, а не просто набор кнопок
С самого начала мы стремились сделать красивый, удобный, гибкий и интуитивно понятный, который поможет реализовать любой пользовательский путь. Сам пользовательский путь проектировали так, чтобы в 90% случаев не нужно было привлекать к решению задач разработчика.
Базовый сценарий пользователя получился следующим:
Создание в системе всех сущностей каталога (характеристики, группы характеристик, категорийное дерево, спецификация/инфомодель).
Импорт, экспорт или создание в UI продуктовых карточек.
Наполнение данными карточек.
Настройка трансляции данных в каналы с помощью Excel или Json.
Расширенный сценарий пользователя предоставляет дополнительные возможности:
Настройка бизнес-правил заполнения характеристик
Настройка подписок на каталог и события обновления в Kafka
Настройка связей продуктов
Создание и использование справочников в продуктах
Управление медиа активами
Интеграции: как другие узнают, что у вас обновилась карточка
В начале пути ставка делалась на то, что UI — это основной способ взаимодействия с системой, и для интеграции пользователю будет достаточно импорта и экспорта сущностей каталога в формате CSV и Excel. Но время шло, и ожидания пользователей относительно автоматизированных способов обновления росли.
Это привело к новым задачам развития — реализации API продуктового каталога на чтение, которое закрывало вопросы экспорта данных из нашей высоконагруженной витрины. Следующим шагом стала автоматизация на уровне записи данных и реализация методов для загрузки данных с возможностью еженедельного обновления в каталоге. Но и этого оказалось мало, и мы реализовали работу с Kafka, в топик которой попадал весь продуктовый каталог и расходился по другим системам компании.
Реализация интеграции с Kafka позволила сделать инструмент подписки на события и получения обновлений в топик при изменении данных в каталоге пользователем. В дополнение к существующим настроенным режимам работы с Kafka мы реализовали ETL-процесс («Extract, Transform, Load — извлечение, преобразование, загрузка») с языком трансформации данных. Пользователь системы с помощью такого инструмента может успешно трансформировать и загружать данные из сторонних систем. Инструмент позволяет взять данные из исходной системы в одном формате и преобразовать в требуемый формат данных при загрузке в систему.
Все эти действия помогли закрыть вопросы интеграционного взаимодействия внутри организации, в которой развернут сервис. После чего мы приступили к реализации интеграции с каналами продаж и трансляции обновлений о продуктах в личные кабинеты маркетплейсов, интернет-магазины и порталы поставщиков по формату Excel (рис. 3) и Wildberries по формату API. В будущем планируется постепенное подключение и всех возможных других API каналов.
Это просто аудит и безопасность
Современные mission critical решения, помимо высокой отказоустойчивости, также должны предоставлять все данные об их текущем состоянии в промышленном контуре. При этом для отслеживания пользовательских действий все изменения в системе должны как минимум фиксироваться, а как максимум — версионироваться, чтобы была возможность откатиться до состояния «как было».
Поэтому мы настроили интеграционные взаимодействия с различными системами мониторинга и аудирования для разбора логов событий в PIM. Также в рамках основной функциональности решили версионировать все сущности, на базе которых строится карточка продукта.
Это позволило пользователю получить актуальную информацию о том, что другие пользователи делают в системе, и удобный инструмент управления версиями каждой сущности и самой карточки продукта (рис. 4)
ИИ поможет или нет?
Одна из важных задач — упростить работу контент-менеджера за счет инструментов на базе ИИ прямо «из коробки». Сейчас, например, в Product 360 уже есть возможность генерировать описание продукта прямо в карточке товара с учетом его характеристик, а также изображение на основе текстового промпта (рис. 5). Про другие сценарии использования ИИ в PIM мы рассказываем здесь.
Так же пользователю доступна функция генерации фото на основе текстового промпта (рис 6).
Результаты и планы на будущее
На старте нашей целью было создание pim-системы для рынка e-commerce, которая отвечала бы высоким требованиям крупных компаний. Как итог, получили on-premise решение, готовое к большим нагрузкам. Сейчас Product 360 — это сервис с безопасностью уровня банковских mission critical решений и интуитивно понятным удобным интерфейсом, помогающим пользователю качественно и быстро решать свои задачи.
В данный момент мы выводим решение на рынок и предлагаем протестировать его возможности.
Запросить консультацию можно здесь.