Реализация автоматического обновления описаний и характеристик товаров
При синхронизации товаров из XML-фида поставщика описания и характеристики перезаписываются, теряя ручные правки контент-менеджера. Это приводит к дублированию работы и ошибкам. Мы реализовали систему раздельного хранения данных с override-механизмом, которая автоматически загружает данные, но приоритет отдаёт ручным изменениям. Такой подход позволяет обрабатывать до 100 000 товаров за 15 минут, что в 30 раз быстрее ручного обновления. За 7 лет работы мы реализовали более 50 проектов по синхронизации каталогов. Оценим ваш проект и предложим оптимальное решение.
Проблемы, которые решаем
- Перезапись ручных правок: если контент-менеджер вручную отредактировал описание, автоматика не должна его затирать. Решение: разделение полей value и supplier_value с флагом is_manual_override.
- Разнородные форматы данных: каждый поставщик присылает характеристики в своём формате. Необходим нормализатор, который приводит всё к единой внутренней схеме.
- Объём данных: каталог из 100 000 товаров требует потоковой обработки, чтобы не упасть по памяти.
- Отсутствие контроля: менеджеры не видят, что изменилось у поставщика, и не могут принять или отклонить изменения.
Как работает система управляемого обновления?
Ключевой принцип: разделять источник данных (поставщик) и финальный контент (что показывается на сайте), с флагом «вручную отредактировано».
CREATE TABLE product_content (
product_id int REFERENCES products(id),
source varchar(30), -- supplier_id или 'manual'
field varchar(50), -- description | spec_weight | spec_color ...
value text,
is_manual_override boolean DEFAULT false,
supplier_value text, -- последнее значение от поставщика
updated_at timestamptz,
PRIMARY KEY (product_id, field)
);При автообновлении: если is_manual_override = true — обновлять только supplier_value, но не value. Контент-менеджер видит расхождение в интерфейсе и решает, принять ли изменение поставщика. Такая архитектура обеспечивает гибкость, подтверждённую практикой.
Почему важно разделять источник данных и финальный контент?
Без разделения любое автоматическое обновление затирает ручные правки. Наш подход с override-механизмом сохраняет изменения редактора, а поставщик всегда видит актуальные данные. Это критично, когда товарные позиции редактируются несколькими людьми.
Источники описаний
XML-фид поставщика
Большинство производственных компаний предоставляют XML с расширенными атрибутами. Парсер на PHP читает файл потоково через XMLReader — это позволяет обрабатывать каталоги любого размера без прожорливости по памяти.
class XmlDescriptionSource implements DescriptionSourceInterface
{
public function fetch(): iterable
{
$xml = new \XMLReader();
$xml->open($this->url);
while ($xml->read()) {
if ($xml->nodeType === \XMLReader::ELEMENT && $xml->name === 'product') {
$node = new \SimpleXMLElement($xml->readOuterXml());
yield $this->parseProduct($node);
}
}
$xml->close();
}
private function parseProduct(\SimpleXMLElement $node): array
{
$data = [
'sku' => (string) $node['article'],
'description' => (string) $node->description,
'attributes' => [],
];
foreach ($node->attributes->attribute as $attr) {
$data['attributes'][(string) $attr['name']] = (string) $attr;
}
return $data;
}
} API с частичным обновлением
Если поставщик предоставляет endpoint изменений, запрос возвращает только товары, у которых изменилось хотя бы одно указанное поле — существенно сокращает объём обработки.
Job-цепочка для обновления контента
Обновление описаний тяжелее обновления цен — контент большой, нужно нормализовать атрибуты, сравнивать с override-флагами. Оптимальная схема: отдельная очередь с низким параллелизмом.
class UpdateProductDescriptionsJob implements ShouldQueue {
public int $tries = 3;
public int $backoff = 60; // секунды между повторами
public function handle(
DescriptionSourceInterface $source,
AttributeNormalizer $normalizer,
ContentUpdater $updater,
): void {
foreach ($source->fetch() as $item) {
$productId = Product::where('sku', $item['sku'])->value('id');
if (!$productId) continue;
$updater->updateField($productId, 'description', $item['description']);
foreach ($item['attributes'] as $name => $value) {
$normalized = $normalizer->normalize($name, $value);
if ($normalized) {
$updater->updateField($productId, $normalized['key'], $normalized['value']);
}
}
}
}
} Логика ContentUpdater
class ContentUpdater {
public function updateField(int $productId, string $field, mixed $newValue): void {
$existing = ProductContent::where([
'product_id' => $productId,
'field' => $field,
])->first();
if (!$existing) {
ProductContent::create([
'product_id' => $productId,
'field' => $field,
'value' => $newValue,
'supplier_value' => $newValue,
]);
return;
}
$existing->supplier_value = $newValue;
if (!$existing->is_manual_override) {
$existing->value = $newValue;
}
$existing->updated_at = now();
$existing->save();
}
} Расписание и приоритеты
| Тип данных | Частота | Причина |
|---|---|---|
| Характеристики (размеры, вес) | Раз в сутки | Меняются редко |
| Описания | Раз в сутки | Большой объём, не срочно |
| Статусы сертификатов | Раз в неделю | Изменяются ещё реже |
| Цены | Каждые 15–30 мин | Высокая волатильность |
Какие ещё источники можно подключить?
Помимо XML и API, возможна интеграция с CSV, JSON, Excel и прямым доступом к базе данных поставщика. Таблица ниже сравнивает основные способы.
| Источник | Скорость обработки | Сложность реализации |
|---|---|---|
| XML-фид | Высокая (потоковая) | Средняя |
| REST API | Средняя (зависит от лимитов) | Средняя |
| CSV (S3) | Высокая | Низкая |
| SQL-реплика | Очень высокая | Высокая |
Интерфейс расхождений в админке
Если value != supplier_value AND is_manual_override = true, показывать в интерфейсе товара предупреждение: «Поставщик изменил значение. Текущее: X, новое от поставщика: Y. Принять?» с кнопками «Принять» и «Оставить».
Типичные проблемы при внедрении
Распространённые сложности и их решения
- Неполные фиды поставщика: иногда в XML отсутствуют обязательные атрибуты. Решение — настроить fallback на дефолтные значения или отправлять оповещение.
- Изменилась структура фида: без версионирования схемы парсер ломается. Хорошая практика — проверять структуру при первом обращении и логировать ошибки.
- Конфликт кодировок: UTF-8 vs Windows-1251. Нормализатор должен автоматически определять кодировку и конвертировать.
Что входит в работу
- Проектирование схемы данных и таблицы product_content
- Реализация парсера для XML-фида или API поставщика
- Нормализатор атрибутов с маппингом названий и типов
- Настройка очередей для фонового обновления
- Интерфейс расхождений в админке
- Тестирование и документация
- Обучение контент-менеджеров
Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальную архитектуру синхронизации. Закажите реализацию автоматического обновления каталога, и ваши менеджеры перестанут тратить время на рутинные правки.







