Налаштування масової зміни статусів товарів 1С-Бітрікс
Сезон закінчився — 200 товарів потрібно зняти з публікації. Акція запускається опівночі — 50 товарів активуються одночасно. Обидва сценарії вирішуються масовою зміною статусів, але неправильна реалізація дає race condition або кладе сайт під навантаженням на MySQL. Ми обслуговуємо інтернет-магазини на Бітрікс з каталогами від 500 до 500 000 товарів, і масові операції — один із ключових компонентів кожного проекту. Наш досвід показує: правильна реалізація може прискорити оновлення статусів у 100 разів порівняно з наївним підходом.
Що таке «статус» товару в Бітрікс
Товар у Бітрікс — елемент інфоблоку з множинними властивостями активності. Основне поле — ACTIVE (Y/N) у таблиці b_iblock_element. Додатково існують часові межі активності: ACTIVE_FROM і ACTIVE_TO — період, в який товар активний. Якщо поточний час не потрапляє в діапазон, елемент вважається неактивним незалежно від значення прапорця ACTIVE.
Кастомні статуси (новинка, акція, хіт, бестселер) — це окремі властивості інфоблоку типу «Список», а не вбудоване поле ACTIVE. Масова зміна кастомних властивостей потребує іншого підходу і розглядається нижче у відповідному розділі.
Чи варто використовувати D7 замість CIBlockElement?
Пряме оновлення через ORM — найшвидший спосіб для поля ACTIVE:
$productIds = [1001, 1002, 1003];
foreach (array_chunk($productIds, 100) as $chunk) {
\Bitrix\Iblock\ElementTable::updateMulti($chunk, ['ACTIVE' => 'N']);
// Скидання кешу для оновлених елементів
foreach ($chunk as $id) {
\Bitrix\Main\Application::getInstance()->getTaggedCache()
->clearByTag('iblock_element_' . $id);
}
}
updateMulti виконує один UPDATE b_iblock_element SET ACTIVE='N' WHERE ID IN (...) — оптимально для MySQL. При оновленні 1000 товарів метод updateMulti у 10 разів швидше за CIBlockElement::Update.
Однак пряме оновлення через ORM оминає події Бітрікс (OnBeforeIBlockElementUpdate, OnAfterIBlockElementUpdate). Як зазначено в офіційній документації Бітрікс, якщо інші модулі підписані на ці події (CRM, пошук, кастомні обробники), потрібно використовувати CIBlockElement::Update():
foreach ($productIds as $id) {
\CIBlockElement::Update($id, false, ['ACTIVE' => 'N'], false);
// 4-й параметр false — без перерахунку прав доступу
}
| Метод | Швидкість (1000 товарів) | Викликає події | Рекомендація |
|---|---|---|---|
updateMulti (D7) |
~1 секунда | Ні | Для простих оновлень без обробників |
CIBlockElement::Update |
~10 секунд | Так | Коли потрібна обробка подій |
Таким чином, метод updateMulti у 10 разів швидше за CIBlockElement::Update.
Відкладена активація за розкладом
Для акційних запусків у конкретний час використовуються поля ACTIVE_FROM / ACTIVE_TO. Не потрібно запускати скрипт опівночі — достатньо задати дати:
\CIBlockElement::Update($productId, false, [
'ACTIVE' => 'Y',
'ACTIVE_FROM' => '01.12.2024 00:00:00',
'ACTIVE_TO' => '31.12.2024 23:59:59',
]);
Бітрікс при відображенні в каталозі автоматично враховує поточну дату. Фільтр у компоненті bitrix:catalog.section за замовчуванням включає ACTIVE_DATE = 'Y', що перевіряє потрапляння в діапазон.
Як змінити кастомні властивості-статуси масово?
Властивість типу «Список» (L) — наприклад, «Статус: Новинка / Акція / Хіт» — змінюється через SetPropertyValuesEx. Для масового оновлення:
- Отримайте ID властивості та значення, яке потрібно встановити.
- Розбийте ID товарів на чанки по 50-100 елементів.
- У циклі викличте
SetPropertyValuesExдля кожного чанка з невеликою затримкою (usleep(50000)). - Скиньте кеш для оновлених елементів.
$enumValues = [];
$enum = \CIBlockPropertyEnum::GetList(
[],
['PROPERTY_ID' => $propertyId, 'VALUE' => 'Акція']
);
if ($enumItem = $enum->Fetch()) {
$enumValueId = $enumItem['ID'];
}
foreach (array_chunk($productIds, 50) as $chunk) {
foreach ($chunk as $id) {
\CIBlockElement::SetPropertyValuesEx($id, $iblockId, [
'STATUS' => $enumValueId,
]);
}
usleep(50000);
}
Умовна зміна статусу
Якщо потрібно змінити статус лише для товарів з певними умовами (наприклад, деактивувати всі товари з нульовим залишком), вибірка робиться заздалегідь:
// Знайти товари з нульовим залишком
$zeroStock = \Bitrix\Catalog\ProductTable::getList([
'filter' => ['QUANTITY' => 0, 'QUANTITY_TRACE' => 'Y'],
'select' => ['ID', 'IBLOCK_ELEMENT_ID'],
])->fetchAll();
$elementIds = array_column($zeroStock, 'IBLOCK_ELEMENT_ID');
// Деактивувати
foreach (array_chunk($elementIds, 100) as $chunk) {
\Bitrix\Iblock\ElementTable::updateMulti($chunk, ['ACTIVE' => 'N']);
}
Цей запит виконується за секунди для тисяч товарів проти хвилин при поелементному обході через CIBlockElement::GetList.
Продуктивність і проблеми race condition
При одночасному оновленні товарів двома операціями (наприклад, хтось натиснув кнопку «Активувати», а в той же момент cron запускає масове оновлення) виникає race condition. Один обробник прочитає старі дані, інший — нові. Результат: втрата оновлень або конфлікти. Рішення — використовувати транзакції та версіонування. Перед оновленням перевіряємо, чи не змінився запис:
$element = \Bitrix\Iblock\ElementTable::getByPrimary($id)->fetch();
if ($element['MODIFIED'] === $knownModified) {
\Bitrix\Iblock\ElementTable::update($id, ['ACTIVE' => 'N']);
} else {
// Запис змінився, пропускаємо
}
Навантаження на MySQL зростає з кількістю товарів. Оновлення 100 000 товарів наївним способом (по одному через цикл) займе години або навіть дні, оскільки кожне оновлення потребує окремого SQL-запиту. Правильний підхід: батчинг (оновлення по 100-500 за раз в одній транзакції). При батчингу час скорочується з годин на хвилини, а навантаження на базу падає в 10-50 разів. Для каталогів понад 100 000 товарів рекомендуємо використовувати cron-агент, який оновлює товари фоном, щоб не блокувати адмінку.
Як інтегрувати масове оновлення з 1С?
При автоматичному оновленні статусів з 1С потрібно відрізняти зміни, що прийшли з 1С, від локальних змін через адмінку. Використовуємо додаткову властивість-прапорець: якщо товар оновлено з 1С, прапорець FROM_1C = Y і зберігається timestamp останньої синхронізації. Це запобігає циклічним оновленням (коли Бітрікс відправляє зміну назад в 1С, а 1С знову повертає його) та дозволяє налагодити синхронізацію в логах. При оновленні товару через CommerceML важливо зберігати локальні перевизначення — наприклад, якщо менеджер вручну деактивував товар, це не повинно бути перезаписано з 1С при черговій синхронізації.
Що входить в роботу під ключ
| Компонент | Опис |
|---|---|
| Прототипування та тестування продуктивності | На вашому обсязі товарів |
| Розробка консолі управління (адмінка) | Для масових операцій |
| Інтеграція з 1С (вартість від 500$) | За потреби |
| Обробка race conditions | Безпека паралельних операцій |
| Кешування та оптимізація індексів | Прискорення запитів |
| Документація та навчання команди | Передача знань |
Ми виконали вже понад 100 проектів з інтеграції Бітрікс та 1С, а наш досвід — 7+ років. Середня економія клієнтів від автоматизації — до 1000$ на рік.
Строки та гарантія
Базова реалізація масового оновлення статусів — 3–5 днів. Повна система з адмінкою, інтеграцією 1С та обробкою конфліктів — 1–2 тижні. Гарантуємо, що оновлення 100 000 товарів виконається за час, який ви визначите (зазвичай — кілька хвилин). Зв'яжіться з нами для консультації — проаналізуємо ваш каталог і запропонуємо оптимальне рішення.
Приклад коду з використанням транзакцій
$connection = \Bitrix\Main\Application::getConnection();
$connection->startTransaction();
try {
foreach (array_chunk($ids, 100) as $chunk) {
\Bitrix\Iblock\ElementTable::updateMulti($chunk, ['ACTIVE' => 'N']);
}
$connection->commitTransaction();
} catch (\Exception $e) {
$connection->rollbackTransaction();
}