1С:Шина изнутри: от сообщения в базе до доставки в другую систему
Содержание
1С:Шина работает как посредник между системами: база 1С кладёт сообщение в канал сервиса интеграции, шина принимает его, прогоняет через процесс интеграции (маршрутизация, преобразование) и доставляет получателю. Отправитель не знает адреса получателя и не ждёт его: если получатель недоступен, сообщение лежит в очереди, пока его не заберут.
Отсюда главный плюс шины перед прямыми обменами «каждый с каждым». Десять баз, связанных напрямую, дают десятки точек отказа и настроек. Через шину каждая система подключается один раз, а правила «кому что отправлять» живут в одном месте.
Из чего состоит 1С:Шина и как идёт сообщение
Шина построена на технологии 1С:Предприятие.Элемент. Это отдельный сервер со своей средой разработки, а не расширение обычной конфигурации 8.3.
Основные части:
- 🖥️ Сервер 1С:Шины — принимает подключения, хранит очереди, исполняет процессы интеграции.
- 🧩 Процесс интеграции — главный объект разработки. Это схема: какие каналы есть, куда идёт сообщение, что с ним делается по пути.
- 📥 Каналы — именованные «трубы», через которые системы отправляют и получают сообщения. У канала есть направление: на вход в шину или на выход из неё.
- 🔀 Элементы схемы — маршрутизация, преобразование, разделение сообщений. Логика пишется на встроенном языке Элемента.
- 🗂️ Информационные системы — зарегистрированные участники обмена (базы 1С и внешние приложения) со своими учётными данными.
- 🔌 Сервисы интеграции на стороне 1С:Предприятия — объект конфигурации в платформе 8.3. Через него база подключается к шине.
Путь одного сообщения
Пример: в УТ провели заказ, его нужно передать на склад (WMS) и в бухгалтерию.
- При проведении заказа код конфигурации формирует сообщение и помещает его в выходной канал сервиса интеграции.
- Платформа записывает сообщение в базу и отправляет его на сервер шины по протоколу AMQP 1.0.
- Шина принимает сообщение во входной канал процесса интеграции.
- Маршрутизатор смотрит на параметры сообщения (тип документа, организацию, склад) и решает, куда его направить.
- Элемент преобразования приводит формат к тому, который ждёт получатель.
- Сообщение попадает в выходные каналы: «WMS» и «Бухгалтерия».
- Получатели забирают сообщения, когда подключены. База 1С-получатель обрабатывает их в процедуре-обработчике канала.
Сообщение состоит из тела (обычно JSON или XML, но шине содержимое не важно) и параметров — пар «ключ-значение» в заголовке. Маршрутизировать по параметрам дешевле, чем разбирать тело: шина не тратит ресурсы на чтение мегабайтного JSON ради одного поля.
Очереди сообщений и гарантированная доставка в 1С:Шине
Очередь — это то, ради чего шину обычно и ставят. Обмен перестаёт быть синхронным: отправитель не зависает, пока получатель думает.
Как это работает на практике:
| Ситуация | Что происходит с сообщением |
|---|---|
| Получатель на связи | Забирает сообщение почти сразу |
| Получатель выключен на ночь | Сообщения копятся в его выходном канале, утром он забирает всё по порядку |
| Нет связи между базой-отправителем и шиной | Сообщение остаётся в базе-отправителе и уходит после восстановления связи |
| Ошибка в обработчике получателя | Сообщение не подтверждено и не теряется; разбираются с ним через диагностику |
Почему сообщение не теряется при сбое
Ключевая идея — сообщение подтверждается только после успешной обработки. Пока получатель не сказал «принял», шина его не удаляет.
На стороне 1С:Предприятия отправка связана с транзакцией. Сообщение, созданное внутри транзакции проведения документа, уйдёт, только если транзакция зафиксирована. Откатилось проведение — сообщения тоже нет. Ситуация «документ не провёлся, а на склад заявка уже ушла» отпадает.
Закладывайте в обработчик получателя идемпотентность: повторная обработка того же сообщения не должна создавать второй документ. Передавайте в параметрах уникальный идентификатор объекта (например, ссылку в виде UUID) и ищите по нему перед созданием. Повторы при сетевых сбоях — нормальное явление для любой шины.
Порядок сообщений
Внутри одного канала сообщения идут в порядке поступления. Если важно, чтобы «изменение заказа» не обогнало «создание заказа», не разносите их по разным каналам с разной нагрузкой. Либо проверяйте версию объекта в получателе и игнорируйте устаревшие данные.
Маршрутизация и преобразование данных в шине
Маршрутизация решает, куда идёт сообщение. Преобразование — в каком виде оно туда придёт. Оба шага задаются в схеме процесса интеграции в среде разработки 1С:Элемента.
Варианты маршрутизации
- 📌 Статическая — всё из канала «Заказы» уходит в канал «WMS». Простейший случай, логика не нужна.
- 🏷️ По параметрам — маршрутизатор читает параметр сообщения. Например,
Склад = Москва→ канал московского склада,Склад = Казань→ казанского. - 📢 Рассылка нескольким получателям — одно сообщение о новом контрагенте уходит в бухгалтерию, CRM и торговлю.
- ✂️ Разделение — пакет на 500 позиций делится на отдельные сообщения, чтобы получатель обрабатывал их по одному.
Когда преобразовывать в шине, а когда в базе
Преобразование в шине удобно, когда получатель — внешняя система со своим форматом. Схему перевода полей меняют в одном месте, а не в каждой базе-отправителе.
Если же обе стороны — типовые конфигурации 1С, проще договориться о едином формате сообщения (например, на основе EnterpriseData) и не нагружать шину лишним.
Пример выше — типичная таблица соответствия, с которой начинают проектирование преобразования. Составьте её до программирования: половина ошибок обмена появляется из-за поля, которое одна сторона считает обязательным, а другая не заполняет.
Подключение базы 1С 8.3 к шине
Подключение идёт в два этапа: разработчик описывает обмен в конфигурации, администратор задаёт параметры подключения в рабочей базе.
В конфигурации
- В дереве метаданных, в ветке «Общие», добавляют объект Сервис интеграции.
- Внутри создают каналы. Имена каналов совпадают с именами каналов процесса интеграции на стороне шины.
- Для каналов на получение пишут обработчик входящих сообщений в модуле менеджера сервиса интеграции.
- В коде конфигурации, там, где возникает событие (проведение, запись элемента), создают сообщение, заполняют тело и параметры, отправляют в канал.
Сервис интеграции — объект конфигурации. В типовую конфигурацию на поддержке его добавляют через расширение или с включённой возможностью изменения. Изменения структуры требуют обновления конфигурации базы данных с монопольным доступом — планируйте это на нерабочее время.
В рабочей базе
В режиме 1С:Предприятия задают адрес сервера шины, имя процесса интеграции и учётные данные. Это делают через стандартную функцию управления сервисами интеграции: её ищут в меню «Функции для технического специалиста», в группе стандартных функций. Там же сервис включают и выключают.
Не переносите копию рабочей базы в тестовый контур с включённым сервисом интеграции. Копия подключится к боевой шине и начнёт забирать или слать настоящие сообщения: склад получит дубли заказов. Сразу после восстановления копии отключите сервис или смените адрес шины на тестовый.
Внешние системы
Не-1С приложения подключаются к шине по AMQP 1.0. Клиентские библиотеки для этого протокола есть для Java, .NET, Python, Go и других языков. Для внешней системы шина выглядит как обычный брокер сообщений с именованными адресами-каналами.
Безопасность и аутентификация участников обмена
Каждый участник обмена регистрируется в шине как информационная система. Ей выдаются учётные данные, по которым она подключается. Без регистрации подключиться к каналам нельзя.
Что настроить обязательно:
- 🔐 Отдельные учётные данные на каждую систему. Не используйте одну пару «логин — секрет» для всех баз. Иначе при утечке придётся менять её везде, а в журналах не будет видно, кто что отправлял.
- 🚪 Права на каналы. Система должна видеть только свои каналы: WMS не нужен доступ к каналу кадровых данных.
- 🔒 Шифрование канала связи (TLS), если шина и базы общаются через интернет или чужую сеть. Внутри закрытого контура решение за вами, но персональные данные сотрудников и клиентов лучше не гонять открытым текстом.
- 🧱 Сетевой доступ. Порт шины открывают только для адресов серверов-участников, а не для всего интернета.
- 🗝️ Хранение секретов. Учётные данные подключения не пишут в код конфигурации и не кладут в общие справочники с широкими правами.
Если через шину идут персональные данные (кадровые сведения, контакты клиентов), процесс интеграции становится частью системы обработки ПДн. Учтите это в документах компании по защите информации и в списке допусков.
Мониторинг шины и разбор ошибок обмена
Шина даёт веб-консоль, где видны процессы интеграции, их состояние и очереди. Смотреть в первую очередь на две вещи: запущен ли процесс и растёт ли число сообщений в каком-то канале.
Растущая очередь — главный симптом. Сообщения приходят, а получатель их не забирает. Причина почти всегда на стороне получателя.
Со стороны 1С:Предприятия смотрите журнал регистрации базы: ошибки подключения и исключения в обработчиках сервиса интеграции попадают туда. Отбор по событиям, связанным с сервисами интеграции, сразу сужает поиск.
Перезапуск процесса интеграции или сервера шины прерывает текущие подключения всех участников. Сообщения в очередях сохранятся, но базы на время потеряют связь и начнут переподключаться. Делайте это в окно наименьшей нагрузки и предупредите ответственных за связанные системы.
Где 1С:Шина оправдана и как строить обмены на ней
Шина нужна не всегда. Для двух баз с обменом раз в сутки хватит типовой синхронизации или выгрузки по расписанию.
| Сценарий | Шина нужна? | Почему |
|---|---|---|
| 2 базы 1С, обмен справочниками раз в день | Скорее нет | Типовая синхронизация проще в поддержке |
| Холдинг: 5+ баз, общая НСИ | Да | Один источник справочников, рассылка изменений всем |
| 1С + WMS + интернет-магазин + CRM | Да | Разные форматы, разные графики работы систем |
| Онлайн-обмен заказами, задержка в секундах | Да | Асинхронная доставка без опроса по расписанию |
| Разовая миграция данных | Нет | Шина не для одноразовых загрузок |
Практики, которые экономят время на поддержке
- Один канал — один тип сообщения. Канал «Заказы» и канал «Контрагенты», а не общий «Обмен». Так проще маршрутизировать и видеть, где застряло.
- Важное — в параметры. Тип объекта, организация, версия формата, уникальный идентификатор. Маршрутизатору не придётся разбирать тело.
- Сообщения небольшие. Документ на 10 000 строк лучше разделить или передавать ссылкой на файл. Большие сообщения медленнее проходят и чаще упираются в лимиты.
- Тестовый контур. Отдельный сервер шины или отдельные процессы интеграции для тестовых баз. Боевые и тестовые каналы не смешиваются.
- Карта обменов. Таблица «канал → отправитель → получатели → формат → владелец». Через год без неё никто не вспомнит, почему справочник уходит в три места.
- Обработка ошибок в получателе. Сообщение, которое не удалось разобрать, логируйте с текстом ошибки, а не просто бросайте исключение. Иначе оно будет падать по кругу.