Налаштування масової зміни статусів товарів 1С-Бітрікс

Налаштування масової зміни статусів товарів 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 — без перерахунку прав доступу } 

Таким чином, метод 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. Для масового оновлення:

1. Отримайте ID властивості та значення, яке потрібно встановити.
2. Розбийте ID товарів на чанки по 50-100 елементів.
3. У циклі викличте SetPropertyValuesEx для кожного чанка з невеликою затримкою (usleep(50000)).
4. Скиньте кеш для оновлених елементів.

$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С при черговій синхронізації.

Що входить в роботу під ключ

Ми виконали вже понад 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();
}