Логи обмена и разбор XML-выгрузки

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

Как устроена сессия обмена

Обмен CommerceML работает как диалог между 1С и точкой входа /bitrix/admin/1c_exchange.php. 1С последовательно шлёт запросы с параметром mode, а сайт отвечает строками success, progress или failure. Понимание этих шагов — половина диагностики.

• mode=checkauth — авторизация, сайт отдаёт cookie сессии;
• mode=init — согласование zip-сжатия и размера части файла;
• mode=file — заливка import.xml, offers.xml и архива картинок в /upload/1c_catalog/;
• mode=import — собственно разбор и запись данных в каталог;
• mode=query / mode=success — выгрузка заказов и подтверждение.

Любой ответ failure со строкой ошибки под ним — это и есть точка, с которой начинается разбор.

Где лежат логи и файлы выгрузки

Битрикс хранит артефакты обмена в нескольких предсказуемых местах. Прежде чем что-то менять, стоит просто открыть эти папки по FTP или в файловом менеджере админки.

Сами XML-файлы (import.xml, offers.xml, prices.xml, rests.xml, orders.xml) — главная ценность: это ровно то, что 1С реально отдала сайту, а не то, что должна была отдать.

Как включить подробное логирование

По умолчанию обмен пишет минимум. Чтобы получить пошаговый протокол, включите ведение файла лога в настройках модулей. В админке это Настройки → Настройки продукта → Настройки модулей → Торговый каталог (и аналогично «Интернет-магазин» для заказов) — параметр пути к файлу лога обмена.

После этого рядом с файлами выгрузки появляется текстовый лог (обычно вида __1c_exchange.log), куда пишутся таймстампы шагов, число обработанных элементов и тексты исключений. Дополнительно фатальные ошибки PHP полезно ловить через журнал событий Битрикса (b_event_log) и лог веб-сервера.

Как читать протокол сессии

Читать лог нужно снизу вверх от последней ошибки. Типичные маркеры и их смысл:

• failure сразу после checkauth — не сходятся логин/пароль обмена или сессия рвётся из-за cookie и редиректов;
• «Превышен интервал ожидания» / таймаут на import — слишком большой файл или тяжёлый разбор, обмен не укладывается в лимит одного шага;
• «Ошибка при создании файла» на file — нет прав на запись в /upload/1c_catalog/ или переполнен диск;
• «Недопустимый элемент» / ошибка парсинга — битый или обрезанный XML.

Обратите внимание на progress: если 1С шлёт import много раз подряд, значит каталог обрабатывается порциями — это нормально, а не зависание. Проблема есть только тогда, когда цикл не заканчивается success.

Разбор структуры CommerceML

Когда лог указал на конкретный товар, открываем XML и смотрим его глазами. Структура CommerceML устроена так, что почти любую проблему видно по ключевым узлам:

• <Классификатор> — группы, свойства и справочники значений; здесь ищут пропавшие разделы и свойства;
• <Товары> → <Товар> — <Ид> (GUID-ключ соответствия), <Наименование>, <Группы>, <ЗначенияСвойств>;
• <ПредложенияПоказать> в offers.xml — цены, остатки и характеристики торговых предложений.

Главный ключ — <Ид>: именно по нему Битрикс сопоставляет запись с уже существующим товаром через таблицу b_xml_tree. Если GUID в выгрузке изменился, сайт создаст дубль вместо обновления — это одна из самых частых причин «размножения» товаров.

Чем валидировать и воспроизводить

Разбирать многомегабайтный XML в браузере бесполезно. Соберите небольшой набор инструментов:

1. Валидатор well-formed XML (любой линтер или xmllint --noout offers.xml) — сразу отсекает обрезанные и битые файлы;
2. Редактор, тянущий большие файлы (Notepad++, VS Code) с поиском по <Ид> проблемного товара;
3. Ручной прогон разбора: положить XML в /upload/1c_catalog/ и дёрнуть 1c_exchange.php?mode=import&type=catalog&filename=offers.xml с параметрами авторизации — обмен выполнится без 1С, а ошибки лягут в лог.

Такой прогон бесценен: он воспроизводит проблему на конкретном файле столько раз, сколько нужно, не дожидаясь регламентного запуска из 1С.

Частые причины по логам

За годы поддержки набор диагнозов повторяется. Если знаешь симптом в логе — знаешь и направление:

• Товары не обновляются — сменились GUID (<Ид>) в 1С, разошлось соответствие в b_xml_tree;
• Обмен обрывается на середине — упирается в max_execution_time, memory_limit или размер части файла из шага init;
• Пропали цены или остатки — не совпадают типы цен и склады между offers.xml и настройками обмена на сайте;
• Дубли свойств — в разных выгрузках у свойства разные <Ид>;
• failure на авторизации — расходятся учётные данные или мешает внешняя защита/редиректы на 1c_exchange.php.

Итог

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

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