Стадии обмена между сайтом на Битрикс и «1С:Предприятие»: режимы и запросы

Как устроен транспорт

Типовой обмен между витриной на «1С-Битрикс» и конфигурацией «1С:Предприятие» идёт в кодировке windows-1251. Все шаги — это последовательные HTTP-запросы к одному обработчику, чаще всего /bitrix/admin/1c_exchange.php. Тип сценария и действие задаются GET-параметрами, например ?type=catalog&mode=checkauth.

Логически выделяют шесть значений type: обмен заказами магазина (sale), сценарий под CRM (crm), загрузка каталога (catalog), highload-справочники (reference), обратная выдача товаров с сайта (get_catalog) и «ожидание изменений» по заказам (listen).

Первый шаг и передача полезной нагрузки

Стартовый запрос почти всегда mode=checkauth: логин и пароль служебного пользователя уходят через HTTP Basic. Успешный ответ текстовый, построчно: флаг успеха, имя сеансовой куки, её значение, затем параметры вида sessid и timestamp, которые стоит подставлять в последующие обращения.

success
PHPSESSID
c84bba7587de83c2b7f88a837ffc4237
sessid=641ec5e7f1547d4934458141ec237512
timestamp=1623238486

Важное отличие от «обычной» отправки файлов формой: тело многих шагов читают как цельный поток из php://input, без разбора стандартного $_FILES и multipart boundary — то, что пришло байтами, и есть файл обмена.

Режим sale: заказы

Цепочка узлов включает:

• checkauth — только проверка учётных данных,
• init — подготовка каталога приёма (часто upload/1c_exchange), контроль .htaccess, согласование использования ZIP,
• query — выборка заказов, изменившихся после последней успешной отдачи,
• success — фиксация времени завершённой выгрузки,
• file — загрузка пакета; при включённом zip ожидается архив, на старых схемах дополнительно валидировали XML,
• import — в новых редакциях: распаковка при необходимости и разбор без промежуточных временных таблиц,
• info — служебные справочники модуля интернет-магазина на стороне сайта.

Режим crm

По шагам близок к sale, но ZIP обычно не задействован, возможна компрессия gz, поддерживаются отбор заказов по идентификаторам и дате «с которой» тянуть изменения — это сценарий связки с CRM, а не «голого» каталога.

Режим catalog: импорт витрины

Здесь последовательность другая по смыслу нагрузки:

• checkauth — авторизация, в ответе участвует timestamp,
• init — очистка рабочей папки (upload/1c_catalog), проверки защитного .htaccess, флаг zip,
• file — приём файла или архива,
• import — многошаговый разбор: при zip сначала распаковка, сброс и создание временных таблиц (с событиями вроде OnBeforeCatalogImport1C), чтение XML в буфер, индексация, перенос метаданных и разделов, деактивация устаревших узлов, импорт элементов, сброс кеша инфоблока и завершающий OnSuccessCatalogImport1C,
• deactivate — деактивация разделов и товаров «старше» переданного timestamp из ответа checkauth,
• complete — формальное закрытие цикла с OnCompleteCatalogImport1C.

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

Режим reference

Работает через каталог upload/1c_highloadblock, шаги checkauth, init, file, import. На старте и финале импорта вызываются OnBeforeCatalogImportHL и OnSuccessCatalogImportHL.

Режим get_catalog

Короткая ветка: init (с проверкой доступа) и query, после которого сайт отдаёт файл выгрузки наружу.

Режим listen

Длинный запрос «подождать изменения заказов»: сервер может держать соединение около минуты. Если появились правки — ответ success, и 1С инициирует обмен заказами; если тихо — пустое тело и HTTP 304 Not Modified, после чего клиент просто отправляет ожидание снова.

Отладка вручную

Чтобы многократно проигрывать те же стадии без постоянной дёрганины живой базы из 1С, удобен отдельный сценарий вроде утилиты bx_1c_sync.php — он повторяет HTTP-диалог из браузера с контролируемыми параметрами.