Довольно много работаем с коробочными Битрикс24 — от энтерпрайзов до поменьше — и почти всегда на таких проектах всплывает тема интеграций. Битрикс24 с чем-то ещё.

Чаще всего это, конечно, 1С. Обычно в виде ЗУП — «Зарплата и управление персоналом». Вполне логично: когда у тебя 1000+ пользователей внутреннего портала, удобнее управлять ими централизованно через одну систему.

В целом для ЗУПа есть штатная интеграция. Пользователей и немного данных она передаёт, но не более.

🔐 Проблема закрытых контуров
Частая история: 1С живёт в изолированном контуре, где интернет даже не ночевал. А интеграция даже у коробочных Битриксов работает через серверы вендора. Получается, что связать «открытый» Битрикс24 и «закрытую» 1С — почти невозможно.

А бывает и хуже: обе системы закрыты, и каждая — в своём контуре. Это уже совсем весело.

🧰 Какие есть варианты интеграции
Разберу по степени сложности и зрелости проекта.

🗂 1. Обмен через файлы
Форматы могут быть любые: CSV, XML, Excel.
1С формирует файл, кладёт у себя. Прокси-сервер, у которого есть доступ и туда, и наружу, отгружает файл в Битрикс24. Дальше всё обрабатывается. Обратно — по той же схеме.

Плюсы:
– быстро
– просто
– дешево

Минусы:
– сложно контролировать
– мало гибкости
– можно сломать одной запятой

🔌 2. API с обеих сторон
На стороне 1С — веб-сервис. На стороне Битрикс24 — обработчик, который знает, что и куда тащить. Прокси по-прежнему нужен. Такой вариант требует больше усилий, особенно если потоков несколько: пользователей гоним, задачи, отпуска, статусы.

Если настроить всё грамотно — один из самых универсальных способов. Особенно если есть потребность в двустороннем обмене.

🛢 3. SQL-шина
Работает как прокси. Оба участника читают и пишут в общую базу. Обычно один поток = одна таблица. Например, пользователи из 1С → в Битрикс24 — это один поток. Можно, конечно, всё в одну таблицу, но тогда больше шансов на косяки.

Хорош тем, что всегда можно зайти, посмотреть, что передано, что зависло, что обработалось. Прозрачно и удобно. Я бы назвал это «шина на коленке», но работает стабильно.

🏗 А если нужно что-то посерьёзнее?
Когда обменов много, системы становятся сложнее, появляется больше направлений и требований по отказоустойчивости — начинают появляться полноценные брокеры сообщений: Kafka, RabbitMQ, всё чаще — Datareon.

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

🤔 Что выбрать?
Зависит от задач. Вот примерная логика:
– если обмен простой и редкий — хватит файлов
– если данные гоняются туда-сюда часто — уже API
– много направлений обмена, хочется прозрачности — SQL
– если проект масштабный и планируется подключение других систем — пора смотреть в сторону брокеров

⚠️ О чём часто забывают
– CSV может поломаться от одной запятой
– API требуют авторизации, логирования, повторных попыток
– SQL-шина без чётких расписаний может вызвать гонки данных
– Kafka и Rabbit — мощно, но требовательно, особенно к инфраструктуре и команде

🔒 Безопасность и устойчивость
Независимо от подхода — критично:
– логировать обмен
– ограничивать доступ
– обрабатывать ошибки
– предусмотреть восстановление после падения

Особенно если данные важные, а обмен идёт в реальном времени.

🧩 Что удобно в реальных проектах
– возможность вручную «толкнуть» данные в систему
– визуализация очередей (видно, что висит и почему)
– простое добавление новых параметров без переписывания всей логики
– защита от потери данных, подтверждение доставки