При работе в распределенной информационной базе (РИБ) специалисты часто сталкиваются с неприятным эффектом: после стандартного обмена между узлами 1С, механизм обмена с интернет-магазином (по протоколу CommerceML) внезапно «решает», что вся номенклатура была изменена, и начинает полную выгрузку данных. Если каталог товаров составляет несколько тысяч позиций, а каждая позиция снабжена изображениями, процесс может затянуться на часы, блокируя нормальную работу. Разберем подробно, почему так происходит, и как оптимизировать этот процесс.
Первым делом нам необходимо понять, как система определяет, что товар нужно отправить на сайт. В основе лежит механизм Планов обмена. Когда любой объект (справочник или документ) изменяется, платформа записывает ссылку на него в специальную таблицу регистрации изменений. План обмена «Обмен с WEB-сайтом» при очередном сеансе просто считывает эти записи.
В ситуации с РИБ проблема заключается в том, что когда данные приходят из удаленного узла в центральную базу, происходит программная запись объектов. Если система настроена некорректно, она воспринимает эту техническую запись как «пользовательское изменение» и ставит товар в очередь на выгрузку. Рассмотрим основные технические факторы, вызывающие этот сбой:
ЦеныНоменклатуры или ТоварыНаСкладах автоматически регистрирует «владельца» (номенклатуру) к выгрузке.ВерсияДанных. Платформа реагирует на это как на изменение объекта в целом.Прежде чем вносить правки в код, нам нужно убедиться, что проблема именно в избыточной регистрации. Выполним следующие действия:
Рассмотрим использование типовой обработки «Регистрация изменений для обмена». Она позволяет наглядно увидеть, какие объекты стоят в очереди. Выберем в поле «Узел» наш веб-сайт и проанализируем дерево объектов. Если напротив справочника Номенклатура стоит число, близкое к общему количеству товаров в базе, значит, массовая регистрация подтверждена.
Попробуем провести эксперимент: очистим регистрацию вручную (нажав правой кнопкой мыши — «Удалить регистрацию»), затем запустим обмен РИБ. Если после завершения обмена цифры в обработке снова «подскочили», значит, виноват именно процесс записи данных из РИБ-узла.
Проанализируем программный код подписок на события. Нам нужно найти те подписки, которые отвечают за регистрацию изменений для плана обмена с сайтом. Обычно это подписки типа ПриЗаписиНоменклатуры или универсальные обработчики регистрации.
Важный момент: в любом обработчике, который занимается регистрацией данных, первой строкой должна идти проверка свойства ОбменДанными.Загрузка. Если это свойство имеет значение Истина, значит, объект записывается механизмом обмена (в нашем случае РИБ), и его не нужно регистрировать повторно для сайта.
Посмотрим на пример правильного кода в обработчике события:
Процедура ПриЗаписиОбъектаДляСайта(Источник, Отказ) Экспорт
// Если выполняется загрузка из РИБ или другого обмена - выходим
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Далее идет логика регистрации изменений
ПланОбмена = ПланыОбмена.ОбменСWebСайтом.НайтиПоНаименованию("ОсновнойСайт");
ПланыОбмена.ЗарегистрироватьИзменения(ПланОбмена, Источник.Ссылка);
КонецПроцедуры
Если в вашей конфигурации такая проверка отсутствует, необходимо ее добавить. Это предотвратит «зацикливание» изменений между разными каналами обмена.
Выясним причину, по которой объекты попадают в очередь автоматически. Откроем конфигуратор и найдем план обмена ОбменСWebСайтом. Перейдем на закладку «Состав».
Здесь для каждого объекта (например, справочника Номенклатура) указан режим авторегистрации. Если установлено значение «Разрешить», то любое изменение объекта платформой (даже без участия программного кода) будет ставить его в очередь. Рассмотрим вариант изменения этого режима на «Запретить».
В этом случае нам придется управлять регистрацией программно, но зато мы получим полный контроль. Мы сможем регистрировать товар к выгрузке только тогда, когда изменились действительно важные для сайта поля (например, цена, описание или наличие), игнорируя технические правки, пришедшие из удаленного офиса по РИБ.
Проанализируем ситуацию, описанную в сообщениях форума, когда номера сообщений в плане обмена остаются нулевыми. Это критическая ошибка. В механизме 1С подтверждение приема данных работает через номера сообщений.
Когда база 1С выгружает данные, она присваивает пакету номер (например, 10). Она ожидает, что при следующем сеансе сайт «скажет»: «Я принял сообщение №10». Только после этого 1С удалит записи из таблицы регистрации изменений. Если сайт не возвращает номер принятого сообщения (или 1С его не обрабатывает), система будет бесконечно пытаться выслать одни и те же 3000 позиций, считая, что прошлая попытка провалилась.
Проверим настройки узла обмена. Убедимся, что после успешной загрузки файлов на сайт, сеанс обмена завершается корректно и номера отправленного/принятого сообщений в плане обмена ОбменСWebСайтом увеличиваются.
Разберем еще несколько нюансов, которые помогут ускорить обмен:
ПередЗаписью.Подводя итог, можно сказать, что «штатное» поведение РИБ в связке с сайтом часто требует ручной донастройки. Основное внимание следует уделить фильтрации изменений через ОбменДанными.Загрузка и контролю над авторегистрацией в составе плана обмена. Применяя эти методы, мы добьемся того, что на сайт будут уходить только реальные изменения, а время обмена сократится с часа до нескольких минут.