Интеграции 1С-Битрикс
Как связать сайт на 1С-Битрикс с внешним миром. Здесь классический обмен с «1С:
Предприятие» по CommerceML и вызовы сторонних API через штатный HttpClient.
Сюда же входят асинхронная отправка SMS и очереди для фоновой обработки.
Отдельно стоят мгновенные события в браузере пользователя через модуль Pull. Три
статьи раздела - это не три похожих способа решить одну задачу. Это три разных
провода наружу и внутрь системы. Первый шаг - понять, какой из них нужен именно
сейчас.
Как устроено
Три статьи - три провода с разным направлением. «Обмен с 1С и HTTP» - связь с внешними системами. Это 1С, маркетплейсы и чужие API, по расписанию или по запросу. «SMS и очереди» - исходящее к конечному пользователю (SMS) и внутренняя асинхронная обработка силами самого проекта (очереди). «Real-time» - единственная статья раздела, где сервер сам инициирует доставку в обратную сторону. Не во внешнюю систему и не в очередь, а в уже открытую вкладку браузера. Прежде чем выбирать API, стоит определить, к какому из трёх проводов относится задача. Это сразу отсекает две статьи из трёх.
Очереди Messenger и команды Pull внешне похожи, но это противоположные механизмы. Оба асинхронны, оба несут небольшой объект данных. Очередь работает в глубину: сообщение уходит от вашего кода к фоновому обработчику. Обработчик запускается когда угодно и сколько угодно раз и годится для тяжёлой или медленной работы. Pull работает в сторону браузера: команда уходит из вашего кода в уже открытую страницу пользователя. Она обновляет интерфейс, и статья прямо предупреждает: это канал уведомлений, а не транспорт для данных. Перепутать их означает уведомить живую вкладку через очередь - сработает только опрос, без эффекта Pull. Обратная ошибка - погнать через Pull тяжёлые данные, для которых нужна очередь. На практике их часто комбинируют: очередь считает тяжёлую работу в фоне. По завершении короткая команда Pull говорит открытой вкладке, что пора обновиться.
У асинхронной отправки в разделе дважды встречается пара «типовой путь плюс путь с полным контролем». Но ось выбора каждый раз своя. У SMS выбор идёт по тому, кто пишет текст. Событие с шаблоном - когда текст правит администратор, а код передаёт только данные. Прямая отправка - когда текст динамический или важен конкретный провайдер. У Pull выбор идёт по тому, известны ли получатели заранее. Отправка конкретному пользователю идёт по идентификатору, а подписка на тег - когда получателей не знаешь. Разослать тогда нужно всем, кто в этот момент смотрит на страницу.
Регистрация через наследование и событие - тот же приём платформы, что и в остальных разделах. Свой SMS-провайдер - это класс-наследник плюс регистрация событием. Тот же паттерн расширения без правки чужого кода описан для модулей и для ядра D7. Раздел «Интеграции» не вводит новый способ подключаться к платформе, а применяет уже знакомый к новой задаче.
Что нужно сделать
| Нужно | Смотрите |
|---|---|
| Настроить обмен товарами и заказами с 1С | Обмен с 1С и HTTP |
| Сходить в чужой API и разобрать ответ | Обмен с 1С и HTTP |
| Отправить SMS и развести долгие задачи по очереди | SMS и очереди |
| Обновить страницу у пользователя без перезагрузки | Real-time (Pull) |
С чего начать
Новичок, которому нужна интеграция с внешней системой. «Обмен с 1С и HTTP» - самая частая задача в проектах на платформе. Сначала разберитесь с понятийным соответствием: контрагенты, номенклатура, характеристики. Потом переходите к штатному HTTP-клиенту, он нужен для остальных API.
Нужно уведомить пользователя или отложить тяжёлую работу. Это статья «SMS и очереди». Но сначала определите, какая из двух её половин подходит. Уведомление конкретного человека и фоновая обработка силами проекта - разные механизмы под одной обложкой.
Нужно обновить интерфейс без перезагрузки страницы. Сразу «Real-time (Pull)», но с одной оговоркой. Без настроенного push-сервера это остаётся обычным опросом с задержкой, а не мгновенной доставкой. Учесть это надо с самого начала.
Темы раздела
- Обмен с 1С и HTTP: связь с внешними системами - 1С по CommerceML и произвольные API через штатный HTTP-клиент.
- SMS и очереди: исходящие уведомления пользователю и внутренняя асинхронная обработка - две разные задачи под одной статьёй.
- Real-time (Pull): единственное направление раздела, где сервер сам инициирует доставку в открытую вкладку браузера.
Практика раздела
- Обмен с 1С - выгрузка товаров и номенклатуры - выгрузка товаров и разбор сбоев.
- Картинки при обмене с 1С - выгрузка изображений товара - как приезжают изображения.
- Обмен заказами с 1С - выгрузка на сайт и обратно - выгрузка на сайт и обратно.
- Цены при обмене с 1С - типы цен, единицы, частичный обмен - сопоставление типов цен.
- Настройка обмена с 1С - узел, доступ, шаги обмена - точка обмена, доступ, шаги.
- Push and Pull в 1С-Битрикс - настройка сервера очередей - сообщения на страницу без перезагрузки.
- REST и вебхуки в 1С-Битрикс - вызовы снаружи и события - вебхуки, своё API, очередь обмена.
- SMS с сайта в 1С-Битрикс - провайдеры, шаблоны, доставка - отправка сообщений и свой провайдер.
Частые вопросы
Как понять, какая из трёх статей раздела нужна для конкретной задачи?
По направлению провода. Если данные идут к внешней системе - 1С, маркетплейс, чужой сервис, - нужна «Обмен с 1С и HTTP». Если речь про уведомление живого человека или про то, чтобы не тормозить запрос тяжёлой работой, - «SMS и очереди». Если нужно обновить интерфейс уже открытой у пользователя страницы без перезагрузки - «Real-time (Pull)», и только она.
Очередь Messenger и команда Pull - для одной и той же асинхронной задачи?
Нет, у них противоположное направление. Очередь передаёт работу вглубь системы - от вашего кода к фоновому обработчику, который выполнит её независимо и может быть не связан с открытой страницей. Pull передаёт короткую команду наружу - в уже открытую вкладку браузера, чтобы обновить то, что видит пользователь прямо сейчас. Пытаться передать через Pull результат тяжёлого вычисления - плохая идея: канал для этого не предназначен.
Можно ли скомбинировать очередь и Pull в одной задаче?
Да, и это рабочий типовой паттерн, хотя явно он ни в одной статье не описан. Тяжёлая часть - импорт, пересчёт, обращение к медленному внешнему сервису - уходит в очередь и считается фоновым обработчиком. Когда работа готова, обработчик отправляет короткую команду через Pull, и открытая у пользователя страница узнаёт об этом мгновенно и подгружает результат обычным запросом, а не через сам канал уведомлений.
Свой провайдер - это всегда наследование класса плюс регистрация событием?
Для интеграций раздела - да, у SMS это описано прямо: базовый класс отправителя и событие, которое отдаёт список доступных провайдеров. Это тот же паттерн расширения платформы без правки чужого кода, что применяется для собственных модулей и для сервисов ядра D7 - его стоит узнавать в разных разделах справочника, а не считать особенностью конкретно интеграций.
Связанные разделы
- Ядро D7 - события и очереди как общий механизм расширения, применённый здесь к SMS и фоновой обработке.
- Модули - собственный модуль - обычное место, где живёт код интеграции с внешней системой.
- Интернет-магазин - обмен с 1С в основном везёт туда и обратно каталог и заказы.
- Инфраструктура - настройка push-сервера для Pull и серверного окружения обмена.