Comments 7
Странно, что вам в 2016 пришлось писать свою PIM, почему не угодили готовые решения?
Ведь те же инфомодели, upsale/crossale они дают прямо из коробки.
У готовых PIM не очень хорошо с раздачей данных по клиентам (сайты, приложения, в т.ч. для сотрудников, терминалы), так что нужен в любом случае промежуточный слой доставки, который потянет нагрузки.
Второй момент - классические PIM всё же про мастер-данные. Операционные (как минимум цены и остатки) могут лежать в классическом ERP, где ведутся в реальном времени. И тогда нужно два потока данных консолидировать, для этого заводится слой бизнес-логики.
В 2016 году была потребность помимо классического функционала PIM системы иметь возможность гибко настраивать отображения контента для разных каналов продаж(приложение продавца, мобильное приложение, сайт, в т.ч. для ценников, которые тоже являются неким подобием карточки товара).
Интересная статья и тематика, но не очень понятна суть и глубина решаемой проблемы. Можете покритиковать наивное решение?
- Поднимаем на swarm кластер, распределенный по нескольким ДЦ
- Ставим Cassandra или Foundation DB
- "Льем" туда данные и обрабатываем (обогащение, дедупликация и т.д.)
- Для организации конвейеров используем Kafka Stream или Apache Storm
Такое чувство, что вы для руководства нарисовали красивую презентацию, чтобы "продать" идею создать свою PIM. Картинки в статье как раз из этой презентации и на них достаточно сложно выглядит система, которая вроде как не должна быть такой сложной.
Какой процент товаров у вас автоматически матчится? И какой вручную?
«М.Каталог» — наш способ организации мастер-данных для всех категорий товаров