Перейти к содержимому
BXWiki

Протокол обмена с 1С - шаги, параметры, ответы, отладка

Разбираем обмен с учётной системой на уровне запросов: шаги, их параметры, ответы сайта и способ повторить любой шаг руками.

Механика

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

Направление обмена задаёт первый параметр запроса. Каталог и заказы идут разными цепочками, у них разный набор шагов и разные ответы на одни и те же имена режимов.

Ответ сайта читается построчно, и главная строка - первая. Слово об успехе означает продолжение цепочки, слово об ошибке останавливает обмен целиком с текстом второй строки.

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

Второй шаг сообщает параметры приёма. Сайт отвечает, принимает ли он архивы и какой размер порции файла считает допустимым для одного запроса.

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

Шаг разбора вызывается многократно для одного файла. Ответ о продолжении означает «вызови меня снова», и цепочка крутится, пока сайт не ответит об успехе.

Именно на этом шаге обмен чаще всего и встаёт. Разбор большого файла не укладывается в отведённое время, ответ о продолжении не приходит, и учётная система считает обмен неудачным.

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

Понимание цепочки экономит часы на разборе. Вопрос «почему не работает обмен» превращается в конкретный вопрос «на каком шаге и с каким ответом он встал».

Шаги

  1. Открыть журнал обмена и найти шаг, на котором цепочка остановилась.
  2. Повторить этот шаг обычным запросом с консоли под тем же пользователем.
  3. Сравнить ответ сайта с ожидаемым для этого шага цепочки.
  4. Разобрать конкретную ошибку: доступ, размер порции, время разбора файла.
  5. Прогнать цепочку целиком и убедиться, что она доходит до успеха.

Код

Проверяем доступ первым шагом:

Окно терминала
URL=https://example.com/bitrix/admin/1c_exchange.php
curl -s -u 'exchange:пароль' "$URL?type=catalog&mode=checkauth"
# ожидаемый ответ: success, затем имя куки и её значение
# любая строка перед ними - посторонний вывод своего кода
# отказ на этом шаге означает права, а не формат данных

Три строки в ответе - признак исправной точки обмена. Любой посторонний вывод перед ними ломает разбор на стороне учётной системы, и обмен не начинается вовсе.

Спрашиваем параметры приёма:

Окно терминала
S='PHPSESSID=значение_из_первого_шага'
curl -s -b "$S" "$URL?type=catalog&mode=init"
# ответ: принимает ли сайт архивы и предельный размер порции файла
# zip=yes означает, что учётная система вправе слать архив
# file_limit задаёт размер одной порции в байтах

Ответ второго шага объясняет странности с большими файлами. Порция задаётся настройкой модуля, и слишком крупное значение упирается в ограничения самого веб-сервера.

Отправляем файл выгрузки:

Окно терминала
curl -s -b "$S" --data-binary @import.xml \
  "$URL?type=catalog&mode=file&filename=import.xml"
# файл кладётся в каталог загрузки сайта под тем же именем
# тело запроса - содержимое файла целиком, без полей формы
# порции дописываются в конец уже созданного файла

Имя файла из параметра запроса определяет и шаг разбора. Каталог, предложения и цены различаются именно именами файлов, а не отдельными режимами обмена.

Запускаем разбор и повторяем до успеха:

Окно терминала
n=0
while true; do
  n=$((n+1))
  r=$(curl -s -b "$S" "$URL?type=catalog&mode=import&filename=import.xml")
  echo "шаг $n: $r"
  case "$r" in progress*) sleep 2;; *) break;; esac   # progress - вызвать снова
done

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

Забираем заказы обратной цепочкой:

Окно терминала
curl -s -u 'exchange:пароль' "$URL?type=sale&mode=query" > orders.xml
head -5 orders.xml            # ответ - файл с заказами к выгрузке
curl -s -b "$S" "$URL?type=sale&mode=success"
# подтверждение помечает выгруженные заказы обработанными

Подтверждение выгрузки помечает заказы обработанными. Без него те же заказы приедут в следующий раз, и в учётной системе появятся дубли документов.

Смотрим, что осталось на диске:

Окно терминала
ls -la /home/bitrix/www/upload/1c_catalog/ | tail -10
tail -50 /home/bitrix/www/bitrix/catalog_export/1c_exchange.log
# файлы и журнал показывают шаг, на котором цепочка встала

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

Проверяем права пользователя обмена:

$user = \Bitrix\Main\UserTable::getRow(['filter' => ['=LOGIN' => 'exchange'],
    'select' => ['ID', 'ACTIVE']]);
print_r($user);   // неактивный пользователь даёт отказ уже на первом шаге
print_r(\CUser::GetUserGroup($user['ID']));   // группы решают право на обмен

Ограничения

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

Время шага разбора ограничено настройками сервера. Крупный файл придётся резать самой учётной системой либо поднимать предел времени для этого адреса отдельно.

Порядок файлов задаёт учётная система, а не сайт. Цены без товаров или предложения без родителей приезжают ровно в том порядке, в каком их отправили.

Ответ сайта нельзя дополнить своим текстом. Любой вывод из своего кода на этом адресе делает ответ нечитаемым для учётной системы и рвёт обмен.

Своя логика подключается только событиями модулей. Править код точки обмена бессмысленно: ближайшее обновление платформы вернёт файл в исходный вид.

Типичные проблемы

Обмен не начинается, ошибка на первом же шаге.

Пользователь обмена неактивен или у него нет права на обмен данными. Доступ проверяют отдельным запросом к точке обмена с его логином и паролем.

Файл приезжает обрезанным или битым.

Размер порции больше того, что принимает веб-сервер на этом адресе. Порцию уменьшают настройкой модуля и повторяют передачу файла целиком.

Шаг разбора крутится и заканчивается ошибкой времени.

Файл слишком велик для одного шага, а предел времени выполнения не поднят. Файл режут на стороне учётной системы либо поднимают предел для этого адреса.

В учётной системе появились дубли заказов.

Подтверждение выгрузки не дошло до сайта, и заказы отдались повторно. Цепочку выгрузки заказов всегда доводят до шага подтверждения.

Учётная система жалуется на неизвестный ответ сайта.

Перед ответом точки обмена печатается посторонний вывод из своего кода. Обработчики событий на этом адресе не должны печатать ничего вообще.

Обмен работает вручную, но не по расписанию.

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

Частые вопросы

Как повторить обмен без учётной системы?

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

Что означает ответ о продолжении на шаге разбора?

Файл разобран не целиком, и шаг нужно вызвать снова с теми же параметрами. Цепочка повторяется, пока сайт не ответит об успехе.

Почему обмен идёт, а данные не меняются?

Файл приехал, но разбор до конца не дошёл или упёрся в настройки импорта. Смотрят журнал обмена и остатки файлов в каталоге загрузки.

Можно ли поменять адрес точки обмена?

Нет, адрес фиксирован платформой, и учётная система обращается именно к нему. Закрывать его переадресацией или фильтром нельзя.

Как добавить свою логику в обмен?

Обработчиками событий модулей каталога и продаж, а не правкой файла точки обмена. Обработчик не должен ничего печатать в ответ.

Смежное

Первоисточник