Обработчики событий обмена с 1С в Битрикс

Стандартный обмен по CommerceML закрывает базовый сценарий синхронизации, но реальный бизнес-процесс часто требует дополнительной логики — уведомить менеджера о новых товарах, пересчитать связанные данные, отфильтровать нежелательные изменения. Разберём, через какие события можно встроиться в процесс обмена с 1С в 1С-Битрикс.

Событие OnBeforeCatalogImport1C и подобные

<?php

use Bitrix\Main\EventManager;

EventManager::getInstance()->addEventHandler(
    'catalog',
    'OnBeforeCatalogImport1C',
    function (&$arFields) {
        // возможность изменить данные до фактического импорта
        if (isset($arFields['NAME'])) {
            $arFields['NAME'] = trim($arFields['NAME']);
        }
    }
);

Обработчики, срабатывающие перед фактическим сохранением данных от 1С, позволяют модифицировать или проверить входящие данные — например, нормализовать формат текстовых полей или отклонить импорт записи, не соответствующей ожидаемому формату, прежде чем она попадёт в базу в неправильном виде.

Событие после успешного импорта элемента

<?php

EventManager::getInstance()->addEventHandler(
    'catalog',
    'OnAfterCatalogImport1C',
    function ($elementId) {
        // логика, выполняемая после того, как элемент сохранён
        recalculateRelatedData($elementId);
    }
);

Событие после сохранения элемента полезно для запуска связанной логики, зависящей от актуальных данных, — например, пересчёт агрегированного рейтинга раздела при изменении входящих в него товаров, или отправка уведомления о появлении принципиально нового товара, которого раньше не было в каталоге.

Точный набор доступных событий зависит от версии и конфигурации

Названия и точный набор событий обмена варьируются между версиями модуля обмена и типом используемой конфигурации 1С — прежде чем писать обработчик, стоит свериться с актуальной документацией или явно найти нужное событие через поиск в коде модуля обмена конкретной установленной версии, а не полагаться на названия событий из устаревших или чужих примеров, которые могли измениться между релизами.

Фильтрация нежелательных изменений от 1С

<?php

EventManager::getInstance()->addEventHandler(
    'catalog',
    'OnBeforeCatalogImport1C',
    function (&$arFields) {
        // не позволять обмену деактивировать товары
        // с активным резервом на складе
        if (isset($arFields['ACTIVE']) && $arFields['ACTIVE'] === 'N') {
            if (hasActiveReservations($arFields['XML_ID'])) {
                $arFields['ACTIVE'] = 'Y';
                AddMessage2Log('Заблокирована деактивация товара с резервом', '1c.import');
            }
        }
    }
);

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

Производительность обработчиков на массовом обмене

Обработчик, зарегистрированный на событие обмена, вызывается на каждый обрабатываемый элемент — тяжёлая логика внутри такого обработчика (например, отдельный SQL-запрос или обращение к внешнему API на каждый элемент) многократно умножается на весь объём обмениваемых данных, заметно замедляя весь процесс. Логику внутри обработчика событий обмена стоит держать максимально лёгкой, вынося тяжёлые операции в отдельный агент, запускаемый после завершения самого обмена, а не выполняемый синхронно на каждый элемент внутри самого процесса синхронизации.

Логирование для диагностики нестандартного поведения обмена

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

Частые ошибки

• Названия событий взяты из устаревшего примера без проверки актуальной версии. Обработчик не срабатывает, поскольку событие переименовано или отсутствует в текущей конфигурации.
• Тяжёлая логика выполняется синхронно внутри обработчика на каждый элемент. Заметное замедление всего процесса обмена, умноженное на объём данных.
• Срабатывание кастомных обработчиков не логируется. Затруднённая диагностика неожиданного поведения при последующем расследовании.

Итог

Обработчики событий обмена дают точку расширения для бизнес-логики, не покрытой стандартными настройками CommerceML, — от модификации входящих данных до реализации специфичных правил вроде запрета деактивации товара с активным резервом. Тяжёлую логику внутри таких обработчиков стоит избегать, вынося её в отдельный агент после завершения обмена, чтобы не замедлять сам процесс синхронизации, умноженный на весь объём обрабатываемых данных.