Паттерны интеграции Битрикс24 и 1С: 5 архитектур на практике

Интеграция Битрикс24 с 1С на поверхности — типовая задача. На практике решается совершенно по-разному, в зависимости от конфигурации 1С, объёма данных, требований к скорости и надёжности. Разбираем 5 паттернов.

Паттерн 1. Типовой обмен CommerceML

Встроенная возможность Битрикс24 обмена с 1С через файлы формата CommerceML. Настраивается за час, бесплатно, подходит для простых случаев: обмен товарами, контрагентами, заказами раз в 15 минут.

Плюсы: просто, бесплатно, не требует разработки.

Минусы: файловый обмен, лаг 15 минут, только стандартные поля, плохо работает при больших объёмах.

Когда использовать: малый бизнес, до 1000 товаров, до 100 заказов/день, стандартные сценарии.

Паттерн 2. Прямые REST API-вызовы

Битрикс24 вызывает REST/SOAP API 1С и наоборот. Без посредников. Обмен по событию: создался заказ в CRM → сразу вызов в 1С.

Плюсы: real-time, простая схема.

Минусы: жёсткая связь систем. Если 1С недоступна, в CRM нельзя создать заказ.

Когда: средний бизнес, где 1С гарантированно доступна.

Паттерн 3. Event-driven через RabbitMQ

Между Битрикс24 и 1С стоит брокер сообщений. Каждое изменение публикуется как событие. Системы подписываются на нужные топики.

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

Минусы: сложнее в разработке и эксплуатации. Нужно решать вопросы идемпотентности.

Когда: enterprise, больше 10000 операций в день, критичность бизнеса.

Паттерн 4. Kafka для стриминга

Для очень больших объёмов — Apache Kafka как шина событий. Вся активность продаж и бухгалтерии течёт потоком. Подписчики — аналитика, BI, warehouse.

Когда: мегакорпорация, миллионы операций в день, развитая BI-инфраструктура.

Паттерн 5. ESB / Сервисная шина

Корпоративная шина (Mule, WSO2, IBM MQ) как центральная интеграционная инфраструктура. Битрикс24 и 1С — просто два из множества подключённых систем.

Когда: уже есть ESB в компании, много систем, централизованная команда интеграций.

Как выбрать

Начните с вопроса: сколько операций в день? До 100 — типовой CommerceML хватит. До 10 000 — REST API. Выше — event-driven. Второй вопрос: что важнее, скорость запуска или качество решения? Для быстрого MVP — REST, для долгосрочного — event-driven.