Обмен 1С ↔ сайт через RabbitMQ

План работ
для 1С-программиста

По этому плану заказчик контролирует подрядчика — видит, какие пакеты и модули он ставит, что пишет, что решает и как проверить, что всё работает.

Ставитпакеты и модули
Решаетконтракт и ключи
Пишетoutbox и публикатор
Сдаётпо чек-листу
Зона подрядчикаВся сторона 1С — он пишет и контролирует обмен целиком.
Зона сайтаСайт предоставляет очереди и разбирает сообщения.
0

Что подрядчик получает на входе

1

Что и как поставить

и как проверить
ШагЧтоКак проверить (заказчику)
1.1Внешняя компонента PinkRabbitMQ (BiteRP, Native API, AMQP 0.9.1). Репозиторий: github.com/BITERP/PinkRabbitMQКомпонента загружена в конфигурацию как макет с двоичными данными (Windows x86/x64 и/или Linux x64 — под разрядность сервера 1С)
1.2Размещение компоненты на серверах приложений 1С (не на клиенте)Подрядчик показывает, где лежит и как подключается (ПодключитьВнешнююКомпоненту)
1.3Проверка разрядностиВерсия so/dll совпадает с разрядностью платформы. Спросить: «что будет после обновления платформы 1С?» — правильный ответ: повторная проверка компоненты в регламенте обновления
1.4Реквизиты подключения — в константах / параметрах сеанса, не в кодеОткрыть модуль: логина, пароля, хоста в тексте кода быть не должно
i
Компонента — это только транспорт (Connect, DeclareQueue, BasicPublish, BasicConsume, BasicAck, BasicReject, GetLastError и т.п.). Вся логика обмена — код подрядчика поверх неё.
2

Что решить до кода

ответ письменно

На эти вопросы подрядчик обязан ответить письменно — по ним потом принимается работа.

  1. Контракт по каждой сущности

    Состав полей, тип, обязательность. Фиксируется и не меняется молча.

  2. Версия точки обмена в имени

    Например import.deal.main.v1. Смена формата = новая версия (.v2), а не тихая правка старой.

  3. Ключ идемпотентности в каждом сообщении

    По нему приёмник отбивает повтор и переупорядочивание. Что берём ключом (id объекта + время изменения) — решает подрядчик, фиксирует в контракте.

  4. Что публикуем событийно, а что по расписанию

    И с какой периодичностью работает регламентное задание.

  5. Сценарий полной перезаливки

    Как выгрузить всё заново, когда стороны разошлись (очередь этого не решает). Отдельный механизм.

  6. Кто администрирует брокер и получает оповещения

    По глубине очереди и dead-letter.

3

Что написать на стороне 1С

!
Про объём. Код — типовой: план обмена, регламентное задание-публикатор, сборка сообщения. Пишется быстро, в том числе с ИИ-агентом, и объём тут не аргумент против брокера. Контролировать нужно не количество строк, а решения из §2 — контракт, ключ идемпотентности и снятие регистрации только после ack. Ошибка будет именно там, а не в обвязке.

Ядро — механизм гарантированной публикации. В терминах 1С объясняется за минуту: outbox = план обмена.

  1. План обмена (outbox)

    На каждую выгружаемую сущность — регистрация изменений. Записал документ/справочник → изменение зарегистрировалось.

  2. Регламентное задание — публикатор

    Читает зарегистрированные изменения, формирует JSON по контракту, публикует в import.<entity>.main.v1. Регистрацию снимает только после ack от брокера. Упал до публикации — изменение уедет в следующий проход.

  3. Формирование сообщения

    Тело по контракту + заголовки: время сообщения, ключ идемпотентности, версия.

  4. Обработка ошибок публикации

    Брокер недоступен → не терять регистрацию, повторить в следующий проход. Самодельный бесконечный повтор не писать — повторы разбора на стороне приёмника даёт брокер.

  5. Входящее — только если нужно

    HTTP-сервис конфигурации. Слушатель очереди внутри 1С не делаем — 1С плохой потребитель.

  6. Инструменты диагностики

    Обязательны, без них брокер — чёрный ящик: посмотреть, что не ушло (осталось в плане обмена), и опубликовать повторно вручную конкретный объект.

4

Карта очередей

типовые сущности Битрикс24

Приёмник на стороне Битрикс24 разбирает эти очереди. Подрядчик публикует в *.main.v1; delayedFirst и failed — служебные, их трогать не нужно. Таблица идёт в порядке зависимостей: сначала справочники, потом документы, которые на них ссылаются.

#Очередь (main)Сущность 1СЧто публикует 1С → куда в Битрикс24
1import.counterparty.main.v1КонтрагентыЮрлица и ИП с реквизитами (УНП/ИНН, адреса, банковские счета), контактные лица → CRM: компания + реквизиты, контакты
2import.product.main.v1НоменклатураКарточка: наименование, артикул, единица измерения, ставка НДС, группа, цена → каталог товаров CRM
3import.contract.main.v1ДоговорыНомер, дата, вид, срок действия, валюта, статус; ссылка на контрагента → CRM-сущность «Договор», привязанная к компании
4import.deal.main.v1СделкиСумма, валюта, стадия, ответственный, товарные позиции (номенклатура, количество, цена, скидка); ссылки на контрагента и договор → CRM: сделка с товарами
i
Связи — только по GUID 1С. Сделка ссылается на контрагента, договор и номенклатуру их идентификаторами из 1С, а не ID Битрикс24: сопоставление делает приёмник. Если сделка пришла раньше контрагента, сообщение уходит в delayedFirst и повторяется, пока ссылка не появится. Новую сущность вводит новая очередь + согласование контракта.
5

Чек-лист приёмки

до того, как обмен принят

Отмечено 0 из 9. Отметки сохраняются только в этом браузере.

6

Что должно насторожить заказчика

Логин / пароль / хост брокера в тексте кода.
Самодельный механизм повторов в 1С (счётчик попыток, своя очередь неотправленного) — план обмена/ack не использован.
Долгоживущее фоновое задание-слушатель очереди в 1С (займёт лицензию, будет рваться).
Публикация сообщения внутри транзакции записи документа.
Имя очереди без версии: import.deal вместо import.deal.main.v1.
Нет ответа на вопросы «что после обновления платформы» и «как перезалить всё заново».
↓

Скачать PDF

A4, ч/б печать

Нужна помощь с обменом 1С ↔ Битрикс24?

Оставьте заявку — обсудим задачу и сроки.