Зацикливание синхронизации 1С с Битрикс: причины и как разорвать круг

Зацикливание синхронизации 1С: как понять, что обмен ушёл в круг

Обмен завершается со статусом «успешно», в логах нет ни одной красной ошибки, а товары и заказы на сайте продолжают меняться. Причём одни и те же. Это и есть зацикливание: каждая сессия обмена формально отрабатывает корректно, но применённый пакет тут же порождает встречное изменение, которое возвращается в следующей итерации. Задача всплывает не в момент первого сбоя, а на второй-третьей ночи, когда штатный обмен по расписанию начинает съедать ресурсы MySQL, а данные на витрине и в учётной системе расходятся всё сильнее.

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

• В журнале обмена повторяются записи с одинаковым набором объектов и одинаковым направлением.
• Очередь на выгрузку не убывает, а держится на одном уровне или растёт от сессии к сессии.
• В соседних сессиях фигурируют одни и те же ID товаров, заказов, складов или цен.
• Нагрузка на MySQL высокая, но число обработанных записей за сессию не увеличивается.

Разница между медленным обменом и циклом видна по динамике очереди. Медленный обмен — это когда пакет на 20 000 позиций обрабатывается долго, но монотонно: размер очереди убывает, а число уникальных ID в выборке растёт. Зацикливание — когда очередь стабилизируется: сколько записей ушло, столько же встало обратно, и состав ID в следующем пакете пересекается с предыдущим почти полностью.

Второй признак — направление изменений. При нормальной синхронизации объект меняется на одной стороне и переносится на другую; обратной записи по нему не возникает, пока его не тронули руками. В цикле по каждому спорному объекту идут две встречные записи: 1С выгружает товар, Битрикс применяет его и по своему правилу регистрации помечает изменённым, следующий обмен забирает это изменение назад в 1С, там срабатывает своя логика регистрации — и объект снова попадает в выгрузку. Смотреть стоит не на общее число записей в журнале, а на пересечение множеств ID между двумя соседними сессиями: при медленном обмене оно близко к нулю, при цикле — к единице. Именно это отличает ситуацию, когда нужно оптимизировать запросы к MySQL, от ситуации, когда нужно искать встречное правило регистрации.

Бесконечный обмен 1С: где именно рвётся логика

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

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

flowchart LR
    A["1С: регистрация изменения"] -->|"выгрузка пакета"| B["Портал: применение"]
    B -->|"запись объекта"| C["Портал: объект изменён"]
    C -->|"выгрузка ответа"| D["1С: применение"]
    D -->|"объект снова изменён"| A

Для диагностики важна не сама причина, а то, с какой стороны приходит повторная регистрация: объект меняется на портале — смотрите обработчики и свойства, меняется в 1С — подписки и правила.

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

Дальше сравните, чем отличается объект до применения и после. Обычно разница в одном-двух полях: дата изменения, статус, служебное свойство. Именно это поле и есть точка разрыва — его пересчитывает то применение, которое должно было быть идемпотентным. Если пакеты совпадают полностью, а обмен всё равно повторяется, проверьте настройки самого узла: интервал и признак «только изменения».

Что делать по шагам: включите подробное логирование на одной итерации, выгрузите оба лога и сопоставьте их по времени. Повторяющийся пакет с одним и тем же XML_ID — надёжный маркер того, что круг замкнулся. Остаётся локализовать сторону, которая его порождает. Разбор причин по каждой стороне — в следующих секциях.

Циклическая синхронизация 1С: причины на стороне 1С

Внутри 1С механизм обмена устроен так, что источником петли почти всегда становятся два узла: правила регистрации изменений и обработчики подписок на события. Первые определяют, какие объекты попадут в очередь выгрузки, вторые срабатывают в момент записи объекта и могут эту очередь пополнить. Если обработчик или правило срабатывает на данные, которые сам же меняет, объект возвращается в очередь сразу после применения входящего пакета — и обмен уходит на следующий круг.

Важно разделить две ситуации. Первая — когда объект попадает в очередь повторно из-за слишком широкого отбора: правило ловит служебные реквизиты, которые портал обновляет при каждом применении пакета. Вторая — когда подписка на событие вносит правку в уже синхронизированный объект, тем самым помечая его как изменённый. Симптом в обоих случаях один: обмен завершается «успешно», а объём пакетов не падает.

Ниже разберём оба механизма и типовую ошибку, которая их объединяет.

Подписки на события: как обработчик меняет объект и снова ставит его в очередь

Подписка на событие в 1С — это обработчик, который выполняется при записи объекта: ПередЗаписью, ПриЗаписи, ПередУдалением. Если в обработчике объекта меняется реквизит, входящий в состав правил регистрации изменений, объект снова помечается на выгрузку. При следующем сеансе обмена он уйдёт на портал, портал вернёт ответную правку, и цикл замкнётся.

Опасны не любые подписки, а те, что пишут в объект без проверки контекста. Типовой пример: при проведении документа обработчик заполняет служебный реквизит «ДатаСинхронизации» или пересчитывает поле, которое участвует в отборе правил. Формально это не ошибка — объект действительно изменился. Но с точки зрения обмена это лишняя запись, которая запускает новый круг.

Разрывать петлю нужно на уровне условия в обработчике: писать только тогда, когда значение действительно изменилось, и не трогать реквизиты, входящие в правила регистрации.

Правила обмена и сопоставление: почему портал считает объект изменённым после применения пакета

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

Типичные источники таких расхождений:

• Цена: 1С присылает 1500.00, портал хранит 1500 — строки не равны, объект «изменён».
• Свойство-список: в 1С это строка, на портале — ID значения перечисления.
• Ссылка на раздел: сопоставление идёт по внешнему коду, а он в пакете пришёл с другим регистром.
• Пустое значение: null из 1С перезаписывает заполненное поле на портале.

Каждое такое расхождение после применения пакета снова помечает элемент как изменённый, и обмен отправляет его обратно. Проверять стоит сами правила сопоставления и типы полей, а не только код: часто достаточно привести сравнение к одному типу и не считать пустое значение изменением.

Как разорвать круг: пошаговый план остановки обмена

Пока обмен идёт, любая правка правила или обработчика бессмысленна: следующая сессия уже стоит в очереди, а изменения вы примените к системе, которая в этот момент продолжает регистрировать объекты. Поэтому порядок жёсткий: сначала остановить очередь с обеих сторон, потом разобрать журнал и найти пакет-виновник, и только затем править логику на одной стороне. Если полезть в код первым делом, цикл вернётся через одну-две сессии: вы уберёте симптом, а источник повторной регистрации останется.

Дальше идёт последовательность шагов, которую мы проходим при разборе зацикливания. Она предполагает доступ к обеим сторонам: к коробке 1С и к админке портала. Без пары сторон круг не разорвать.

1. Остановить обмен на обеих сторонах: в 1С снять расписание регламентного задания синхронизации, в Битрикс отключить агента обмена. Пока хотя бы одна сторона продолжает инициировать сессию, очередь будет наполняться заново, и вы не увидите чистую картину в журнале. Отключение — не разовая кнопка: убедитесь, что не осталось ручных запусков по расписанию cron.
2. Снять дамп очереди обмена и сохранить журнал сессий: выгрузить таблицу очереди в SQL-дамп и забрать лог обмена за последние несколько циклов. Нужны именно соседние сессии, по ним видно, какие ID объектов повторяются из раза в раз. Дамп сохраните до правок: после исправления сравнить будет не с чем.
3. Найти повторяющийся пакет и определить сторону, которая первой ставит объект в очередь. Сопоставьте ID из дампа с записями журнала на обеих сторонах: где объект впервые попал в очередь, там и источник петли. Именно эту сторону дальше и правите.
4. Исправить правило регистрации или обработчик на одной стороне, не на обеих сразу. Если источник в 1С, правьте правило регистрации изменений или подписку; если на портале, обработчик, который меняет объект после применения пакета. Одновременная правка двух сторон не даст понять, что именно сработало.
5. Запустить обмен вручную на одном объекте и проверить, что повторной регистрации нет: возьмите конкретный товар, прогоните его через синхронизацию и посмотрите очередь после завершения. Объект не должен появиться в ней повторно. Если появился, возвращайтесь к шагу 3: источник найден неверно.

Ошибка обмена 1С: таблица симптомов и решений

Зацикливание редко приходит в одиночку. В тот же период в логах всплывают ошибки прав, блокировки MySQL, несовпадение версий модуля обмена. Их легко принять за причину петли и начать чинить не то. Мы видели проекты, где неделю правили правила регистрации, а обмен останавливался из-за таймаута на стороне веб-сервера. Поэтому первое, что стоит сделать, — разложить симптомы по категориям: что именно сообщает система, на каком шаге, повторяется ли ошибка в каждой сессии или возникает разово.

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

Для диагностики сначала смотрим на код ответа: 401 и 403 — это права, 500 — чаще всего разбор пакета или блокировка, зависание без ответа — таймаут.

Главное отличие ошибки обмена от зацикливания в том, как система ведёт себя с пакетом. Ошибка останавливает обработку: пакет не применяется, попадает в лог как неудачный, и следующая сессия начинается с того же места. Цикл же пакет применяет — успешно, без красных строк, — но тут же формирует новый пакет с изменёнными объектами. Внешне это выглядит как нормальный обмен: статус «успешно», очередь движется, товары на сайте обновляются.

Различить их можно по трём признакам. Первый — наличие ошибки в логе: если есть хотя бы одна красная строка, это сбой, а не петля. Второй — повторяемость: ошибка воспроизводится на одном и том же объекте, цикл затрагивает разные. Третий — динамика очереди: при ошибке очередь стоит или растёт, при цикле она постоянно пополняется новыми пакетами.

Если ошибка и цикл совпали, сначала устраняем ошибку, потом смотрим, осталась ли петля. Часто зацикливание оказывается следствием: система не может применить пакет, откатывает его, регистрирует изменение снова — и так по кругу. Поэтому чинить нужно в обратном порядке.

1С синхронизация зациклилась: как проверить, что круг разорван

После правки правила регистрации или обработчика подписки нужно не «посмотреть, стало ли лучше», а проверить конкретное условие: обмен проходит несколько сессий подряд, и ни один ID не регистрируется повторно. Пока это условие не выполнено, петля просто замедлилась — та же пара «портал изменил объект → 1С увидел изменение → выгрузил обратно» продолжает работать, только с меньшей амплитудой. Проверка занимает один рабочий цикл обмена. Останавливать продакшен не нужно: смотрим журнал, очередь и счётчик уникальных ID по сессиям.

Ниже минимальный набор проверок, который отделяет настоящее разрывание круга от временного затишья.

• Журнал обмена: за N последних сессий нет ни одной повторной выгрузки одного и того же объекта.
• Очередь обмена: после применения пакета она опустошается, а не наполняется новыми записями.
• Нагрузка на MySQL: число записей в таблице очереди не растёт линейно от сессии к сессии.
• Повторные ID: один и тот же элемент не фигурирует в трёх и более сессиях подряд.
• Ручной обмен одного объекта: правка в 1С даёт ровно один проход, без обратной регистрации на портале.

Читайте также: Обмен Битрикс24 и 1С: как настроить синхронизацию и не сломать каталог, Невосстановимая ошибка СУБД 1С: причины и решение.

Подробнее об услуге: интеграция 1С с сайтом и CRM.