Боль, привычка или искусство?

Довольно много работаем с коробочными Битрикс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 — мощно, но требовательно, особенно к инфраструктуре и команде

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

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

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