Ситуация, когда в распределенной информационной базе (РИБ) номера отправленных сообщений начинают бесконтрольно расти («бежать вперед»), является критической для стабильной работы торговой сети. В конфигурации 1С:Розница 8. Аптека (и в других решениях на базе БСП) это приводит к тому, что периферийные узлы перестают принимать данные из центра, так как ожидают пакет с определенным номером, а получают либо слишком старый, либо слишком новый. Рассмотрим подробно, почему это происходит и как восстановить работоспособность обмена.
В типовом механизме РИБ каждый узел ПланаОбмена хранит два ключевых реквизита: НомерОтправленного и НомерПринятого. В идеальной ситуации обмен выглядит так: Центральная база (ЦБ) отправляет пакет №10, периферийный узел (ПЗ) принимает его, обрабатывает и в ответном сообщении присылает подтверждение: «Я принял номер 10». Только после этого ЦБ считает данные доставленными и очищает таблицу регистрации изменений.
Проанализируем ситуацию, когда номера в ЦБ начинают расти (11, 12, 13...), а подтверждения от ПЗ не приходят. Основные причины:
Прежде чем исправлять номера, мы должны убедиться, что проблема не повторится. Выясним, нет ли неучтенных копий базы. Для этого выполним следующие действия:
Во-первых, проанализируем Журнал регистрации в центральной базе. Ищем события по фильтру «Синхронизация данных» и смотрим, с каких IP-адресов или под какими именами компьютеров инициировались успешные сеансы. Если видим подозрительную активность — это явный признак «базы-клона».
Во-вторых, временно сменим пароль на FTP-сервере или доступ к сетевой папке. Это самый эффективный способ «отстрелить» все забытые тестовые базы и скрипты, о которых администратор мог не знать.
В-третьих, проверим консоль кластера серверов 1С. Посмотрим список активных сеансов и фоновых заданий. Если для одного и того же узла обмена запущено несколько фоновых заданий ВыполнениеОбменаДанными, необходимо разобраться с расписанием.
Посмотрим на настройки синхронизации в интерфейсе программы. В 1С:Розница часто используется механизм Сценарии синхронизации данных. Если для одного узла настроено несколько сценариев (например, один по расписанию, другой по событию), они могут конфликтовать.
Проверим состояние регистрации изменений. Если в узле зарегистрировано огромное количество объектов, которые не могут выгрузиться из-за ошибки в данных, система будет пытаться отправить их снова и снова, увеличивая номер сообщения, но не получая подтверждения. Воспользуемся стандартной обработкой РегистрацияИзмененийДляОбменаДанными и проанализируем состав отправляемых данных.
Если номера уже «разбежались» настолько, что автоматический обмен невозможен, нам придется выровнять их вручную. Выполним это по строгому алгоритму, чтобы не потерять данные.
Важно: Перед выполнением этих действий обязательно отключите все регламентные задания обмена в обеих базах!
Message_*.xml.Рассмотрим пример кода для программного сброса номеров, если стандартный интерфейс не позволяет это сделать:
// Выполнять в обеих базах для соответствующего узла
УзелОбъекта = ПланыОбмена.ПоОрганизации.НайтиПоКоду("АП1").ПолучитьОбъект();
УзелОбъекта.НомерОтправленного = 0;
УзелОбъекта.НомерПринятого = 0;
УзелОбъекта.Записать();
После того как в обеих базах установлены значения 0-0, выполним ручной запуск синхронизации:
Иногда простого изменения реквизитов узла недостаточно, так как БСП хранит дополнительную информацию в регистрах. Проанализируем состояние регистра сведений СостояниеОбменовДанными. Если в нем зафиксирована критическая ошибка для конкретного номера сообщения, система может блокировать последующие попытки.
Также стоит обратить внимание на регистр НастройкиТранспортаОбменаДанными. Убедимся, что пути к папкам указаны корректно и нет дублирующих записей для одного и того же узла с разными способами доставки (например, одновременно FTP и локальный диск).
Поскольку мы работаем с редакцией 2.2, важно помнить о возможных блокировках на уровне платформы. В файловом варианте базы часто возникают проблемы с правами доступа к папке temp пользователя, под которым работает сервер 1С. Проанализируем права: у пользователя, от имени которого запущен rphost (или служба 1С), должны быть полные права на чтение/запись в каталог обмена.
Если после ручного выравнивания номеров ситуация повторяется через несколько дней, попробуйте изменить Префикс информационной базы для проблемного узла (и соответственно переименовать файлы). Это поможет исключить влияние старых, «зависших» где-то в кешах или на промежуточных серверах сообщений.
Подведем итог. Чтобы победить «бегущие» номера в РИБ, мы должны действовать системно: устранить сторонние источники обмена, очистить транспортный каталог и синхронно обнулить счетчики. В дальнейшем рекомендуем настроить мониторинг обмена, который будет уведомлять администратора не только о факте ошибки, но и о резком расхождении номеров отправленных и принятых сообщений. Это позволит локализовать проблему до того, как она приведет к полной остановке обмена во всей сети из 17 узлов.