Комментарии 15
А можно ли использовать эти системы, как продуктовый каталог для Интернет-магазинов? То есть не делать хранение товаров в отдельном движке, скажем, opencart, а использовать PIM, и просто доделать всякие страницы типа «О магазине», «Корзина» и пр?

Вопрос связан с тем, что я последнее время думаю, что хорошо бы кроме интернет-магазина иметь еще возможность строить лендинги с подтягиванием продукта, а часть продуктов вынести на другие типа сайтов, например, оптовый. То есть иметь один мастер-истоник продуктов со сквозными id. Кажется, из того, что я прочел — PIM может решить такую задачу?
Да, PIM системы для этого и созданы чтобы являться центральной системой где хранится и создается вся продуктовая информация. Затем уже когда информация создана и проверена (PIM может делать проверки автоматически) она выгружается (экспортируется) в другие системы, такие как веб сайты, маркеплейсы и т.д.

Иметь систему для интернет магазина все равно надо, но в ней теперь можно иметь только нужную информацию. Например для оптового магазина можно иметь специальные цены, условия поставки и т.д., а для розницы этого не надо. Маркеплейсы требуют чтобы товар был в нужной для них категории (а они разные для каждого маркетплейса) поэтому можно иметь все типы категорий в PIM и выгружать уже нужную в каждый маркетплейс и т.д.

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

Более того, PIM системы в первую очередь предназначены для мастер-данных, не для операционных. То есть цены там вести можно, но — не супер идея.
Согласен полностью. Только немного не так бы сказал, управлять ценами в PIM не стоит (если есть другие варианты), то есть источником цен обычно PIM не является, это обычно ERP. Но цены это очень важная часть продуктовых данных, поэтому без них никуда. Часто их импортируют из других систем, затем добавляют в продуктовую информацию все что надо и выгружают уже готовую информацию.
Хотя на моей практике в примерно половине внедрений PIM где я участвовал цены были именно в PIM (так что это не догма)
Тут самый главный вопрос в том, насколько часто цены меняются. Экспорт мастер-данных из PIM — процесс тяжёлый, зато его на условную «витрину» достаточно делать раз в сутки или того реже, и то — только изменения. Если окей менять цены с такой частотой, то да, можно их гонять по маршруту ERP -> PIM -> витрина.

Если есть необходимость менять чаще — то без вариантов придётся заводить 2 параллельных потока: мастер-данных (из PIM) и цен (из ERP) в тот самый кэш товаров, и уже оттуда агрегированные данные показывать покупателям.
согласен. У нас цены часто не менялись, поэтому выгружали их из PIM.
А как выглядит типовая интеграция MDM и PIM? С точки зрения процесса.
PIM считается частью MDM. То есть PIM это Product MDM, есть еще например Customer MDM, Location MDM и т.д.

MDM это система которая получает данные из нескольких источников, очищает их, убирает дубликаты. В классических MDM системах происходит процесс матчинга (то есть нахождения потенциальных дубликатов) потом идет merge (слияние) когда генерируется так называемая «золотая запись» (то есть наиболее правильная информация о той сущности с которой работает MDM)

Дорогие PIM системы которые расчитаны на большие компании все это поддерживают и для продуктов, но обычно для продуктов не всегда нужен такой сложный процесс матчинга и слияния, необходимо просто иметь центральную систему которая может управлять продуктовой информацией. Плюс еще товары обычно активно используют изображения и файлы (а MDM обычно плохо умеют работать с такими данными), плюс товар обычно связан со многими иерархиями, плюс атрибуты товаров зависят от иерархии (бутболки имеют свои атрибуты, а телевизоры — другие) и т.д.

То есть PIM это такой специфичный MDM который имеет дополнительную функциональность которая не нужна для других сфер где работает MDM.

И часто PIM системы это еще и MDM (опять же для крупных и сложных проектов). Тот же Pimcore еще и MDM. Еще например Stibo (одна из известных PIM систем) это и PIM и MDM и т.д.

Ну и если в компании есть какой-то MDM и его надо интегрировать с PIM то интеграция делается как и со всеми другими системами через обмен файлами или напрямую через API
По первым двум PIM-системам, поставить их на сервер еще не каждый сможет.
По третьей не нашел системные требования. Ставить из докера как бы можно, но хотелось бы котролировать весь процесс.
Ну и последнее. Я бы рекомендовал мелкому и среднему бизнесу все-таки обратить свое внимание на данную систему demo.atropim.com (ранее она развивалась под брендом TreoPIM).
Гибкая, легкая в установке (через композер), можно создавать любые свои сущности с разными типами связи. Есть допмодули, но они к сожалению платные и довольно дорогие.
согласен про устновку, я помучался с установкой Akeneo и Pimcore…

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

Если хочется запустить OpenPIM без докера то могу рассказать как (напишите в личку). Можете глянуть в исходники, там все просто. UI сделан на Vue и может быть скомпилирован и выложен через любой HTTP сервер (в докере используется Nginx). Сервер это node.js (express) его тоже легко запустить. надо только подправить .env файлы для конфигурации этих двух частей.

Что касается системных требований к OpenPIM, то надо иметь запущенным 3 компонента: HTTP сервер, node процесс и postgres SQL. Все это легко запустится даже на 1 Гб памяти, процессор мало важен.

У нас получилось завернуть PIMCore в Docker Swarm, на самом деле это тот еще квест оказался, даже если он на первый взгляд работает — при обновлении или редеплое он легко случайно превращается в тыкву.


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


И таких заморочек там много. Поэтому для поиграться я бы не рекомендовал запускать его в докере (штатные Dockefiles что идут в комплекте большей частью бесполезны)


А вот сетап через композер на сервере достаточно безпроблемен и легок для изучения системы.

А как у этих систем с API? Хотя бы для простого получения данных

конечно есть, у всех. У Akeneo и Pimcore есть REST API. У OpenPIM — graphgl.
Вытаскивать данные вообще без проблем.

Это кардинально меняет дело, если есть возможность внедрить в существующую систему как отдельный независимый сервис, а не файлики экспортить/импортить.

Pimcore deprecated REST API. В следующей версии его уже не будет.
Вместо него они представили DataHub, который собственно предоставляет GraphQL к данным внути PIM

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.