Представьте: 14 магазинов, центральная база в Самаре, периферийные узлы в каждой точке. После каждого обмена с узлом 1С запускает обработчики обновления заново. Снова и снова. Кассиры ждут. Менеджеры ждут. Директор звонит.
Я лично столкнулся с этим на одном из проектов — и скажу честно, первые полчаса вообще не понимал, где искать причину. Знакомо? Это классическая боль распределённых баз — РИБ (Распределённая информационная база) в 1С. И у неё есть решение.
Что такое РИБ и почему обработчики запускаются повторно — главная проблема 1С в распределённых сетях
РИБ — это когда одна база 1С «размножена» по нескольким точкам. Центральный узел в офисе, периферийные — в магазинах, складах, филиалах. Они синхронизируются через обмен данными: пакеты XML туда-обратно, всё красиво.
Но вот беда. Когда периферийный узел получает пакет от центра — 1С воспринимает это как «что-то изменилось» и запускает обработчики обновления информационной базы. Те самые, которые обычно срабатывают один раз при обновлении конфигурации.
Один раз — окей. А если обменов 10 в день? 20? При каждом — повторный запуск. Пользователи видят «Выполняется обновление...», ждут, нервничают. На одном из моих проектов — сеть из 9 аптек в Екатеринбурге — это съедало до 40 минут рабочего времени в день суммарно по всем точкам. Просто на ожидание. Каждый день.
Зачем это вообще происходит? Платформа 1С не всегда умеет «понять», что обмен с узлом — это не обновление конфигурации, а просто данные пришли. Особенно если в конфигурации есть процедуры в модуле ОбработкаОбновленияИнформационнойБазы.
Как 1С решает эту задачу — механизм версий конфигурации в РИБ
Ладно, погнали по механике. В 1С есть понятие версии конфигурации базы данных. Платформа сравнивает её с версией конфигурации в метаданных. Если они совпадают — обработчики не запускаются. Если нет — запускаются.
При обмене в РИБ в пакете передаётся, в том числе, информация о конфигурации узла. И вот здесь — ключевой момент: если версии конфигурации центрального и периферийного узла расходятся (даже незначительно, даже технически), платформа считает, что «что-то обновилось», и запускает обработчики.
Причин расхождения версий бывает несколько:
- Центральный узел обновили, а периферийный ещё не получил пакет с новой конфигурацией
- В коде обработчика обновления не предусмотрена проверка — «а не запускался ли я уже?»
- Разработчик написал обработчик без учёта РИБ-специфики
- Конфигурация нестандартная, сильно доработанная — и логика версионирования «поехала»
Короче говоря, проблема не в самой платформе. Проблема в том, как написан обработчик.
Три рабочих способа отключить повторный запуск обработчиков в 1С РИБ
Ну вы поняли, к чему я веду. Вот что реально помогает — три конкретных способа, без воды.
Способ 1 — Проверка версии внутри обработчика
Самый правильный и надёжный способ. В процедуре ОбработкаОбновленияИнформационнойБазы добавляется проверка: если текущая версия базы уже соответствует ожидаемой — выходим, ничего не делаем.
Это делает программист 1С — руками, в конфигураторе. Занимает от 1 до 4 часов в зависимости от объёма обработчиков. Результат: обработчик запускается ровно один раз при реальном обновлении, и никогда — при обменах с узлами.
Марина, главбух той самой аптечной сети из Екатеринбурга, после такой доработки написала: «Наконец-то утро не начинается с жалоб кассиров». Это, пожалуй, лучший отзыв за тот проект.
Способ 2 — Флаг в константе или регистре сведений
Чуть более грубый, но тоже рабочий вариант. Создаётся константа или запись в регистре сведений — своеобразный флажок «обработчик уже отработал для этой версии». Перед запуском обработчика — проверка флага. Если поднят — пропускаем.
Минус: флаг тоже передаётся при обмене между узлами. Нужно аккуратно настроить состав данных обмена, чтобы этот флаг не «затирался» при синхронизации. Иначе получите ровно ту же проблему, только в другом месте.
Способ 3 — Настройка плана обмена и состава данных
Это уже уровень архитектуры. В плане обмена РИБ можно явно указать, какие объекты и данные передаются между узлами. Если исключить из состава обмена те объекты, изменение которых провоцирует запуск обработчиков — проблема уходит.
Но здесь нужна осторожность. Исключить лишнее — легко. Случайно исключить нужное и потом три дня искать, почему данные не синхронизируются — тоже легко. Я считаю, что это работа опытного 1С-ника, не для самостоятельных экспериментов — особенно если конфигурация сильно доработана.
Что проверить прямо сейчас — чек-лист для 1С РИБ
Если у вас РИБ и вы подозреваете эту проблему — вот что смотреть.
- Журнал регистрации (меню «Администрирование → Журнал регистрации»): ищите события типа «Обновление информационной базы» — как часто они происходят? Если после каждого обмена — проблема подтверждена
- Версия конфигурации на центральном и периферийных узлах: «Справка → О программе» — версии должны совпадать везде, где уже прошло обновление
- Время обмена: если обмен занимает 2 минуты, а пользователи «висят» 10-15 — значит после обмена что-то ещё запускается. Скорее всего — те самые обработчики
- Количество узлов: чем больше узлов, тем острее проблема. При 3-5 точках — терпимо. При 10+ — критично
- Частота обменов: если обмен раз в сутки — вы можете не замечать проблему. Если каждые 15 минут — боль ощутимая
Ещё один момент — и сейчас будет важное, не пропустите. Иногда проблема вылезает не сразу, а после очередного обновления конфигурации. Разработчик добавил новый обработчик, не подумал про РИБ — и понеслось. Поэтому любое обновление конфигурации в РИБ-среде нужно тестировать именно на предмет повторных запусков.
Сколько это стоит починить и стоит ли вообще
Если честно — стоит. Почти всегда.
Посчитаем грубо. 10 точек, 3 пользователя на каждой, обмен 6 раз в день, каждый раз ожидание 5 минут. Итого: 10 × 3 × 6 × 5 = 900 минут потерянного рабочего времени в день. 15 часов. Каждый день.
При средней стоимости часа работы сотрудника 300-400 рублей — это 4 500-6 000 рублей в день. В месяц — 90 000-120 000 рублей просто на ожидание.
Доработка у нормального 1С-ника занимает 4-8 часов работы. Стоимость — в разы меньше месячных потерь.
Ну вот, собственно, и вся математика.
Единственный случай, когда можно не чинить — если у вас 2-3 узла, обмен раз в сутки ночью, и пользователи в момент обмена не работают. Тогда это просто шум, не боль.
Если в 1С регулярно возникают такие задачи, и времени на них не хватает — делегируйте разовым спецам на koderion.ru. Биржа 1С без посредников, оплата по часам, без трудовых договоров.
Сохраните статью 🔖 — пригодится, когда столкнётесь с этим на практике. И напишите в комментариях: у вас есть РИБ? Сколько узлов? Интересно собрать статистику.