Содержание:

1. Как определить архитектуру решения
2. Определение способов реализации слушателя (Consumer) на стороне 1С
3. Примеры бизнес-логики в 1С

В эпоху Индустрии 4.0 предприятия все активнее внедряют IoT (Интернет вещей) для мониторинга производственных процессов в реальном времени. Однако интеграция потока данных от сотен и тысяч датчиков с корпоративной учетной системой, такой как 1С, является нетривиальной задачей. Прямые HTTP-запросы к 1С от каждого устройства создают колоссальную нагрузку и не обеспечивают должной отказоустойчивости. Решением этой архитектурной проблемы является использование брокера сообщений, и одним из самых эффективных инструментов для этого выступает RabbitMQ.

Как определить архитектуру решения

В основе интеграции лежит принцип разделения (decoupling) производителя данных (IoT-устройство) и потребителя (система 1С) через промежуточный буфер — брокер сообщений.

1. IoT-устройство (Publisher): Датчик температуры, счетчик продукции на конвейере или станок с ЧПУ периодически собирает данные. Эти данные упаковываются в легковесный формат (чаще всего JSON) и отправляются как сообщение в RabbitMQ. Устройство не знает о существовании 1С и не ждет ответа, что делает его работу быстрой и автономной.
2. RabbitMQ (Broker): Выступает в роли почтового сервера. Сообщение от устройства попадает в Exchange (обменник), который, основываясь на правилах маршрутизации (Routing Key), направляет его в одну или несколько очередей (Queue). Эта очередь гарантирует доставку: если система 1С временно недоступна (например, во время обновления или регламентных работ), сообщения будут накапливаться в очереди и не потеряются.
3. Система 1С (Consumer): Выступает в роли подписчика (потребителя) на определенную очередь в RabbitMQ. 1С забирает сообщения из очереди, разбирает (парсит) JSON и выполняет необходимую бизнес-логику на основе полученных данных.

Определение способов реализации слушателя (Consumer) на стороне 1С

Существует несколько подходов для организации получения сообщений из RabbitMQ в 1С:

• 1. Внешняя компонента (Native API): Наиболее производительный способ. Используется внешняя компонента (DLL), которая предоставляет 1С прямой доступ к протоколу AMQP. Это позволяет организовать постоянное соединение и асинхронную обработку сообщений, минимизируя задержки. Метод требует навыков разработки или использования готовых коммерческих/open-source компонент.
• 2. Промежуточный сервис-коннектор: Самый гибкий и надежный подход. Легковесный сервис (написанный на Python, Go или C#) постоянно слушает очередь RabbitMQ. При получении сообщения он вызывает опубликованный HTTP-сервис 1С и передает ему данные. Этот метод изолирует 1С от деталей работы с брокером и позволяет легко масштабировать систему.
• 3. Регламентное задание: Самый простой в реализации, но не real-time способ. В 1С создается регламентное задание, которое с заданной периодичностью (например, раз в минуту) подключается к RabbitMQ через HTTP API самого брокера, забирает накопившиеся сообщения из очереди, обрабатывает их и отключается. Этот метод подходит для задач, не требующих мгновенной реакции.

Примеры бизнес-логики в 1С

После получения и парсинга данных с датчика, 1С может выполнять следующие действия:

• Создание документов: При получении данных со счетчика на конвейере автоматически формируется документ «Выпуск продукции» или «Отчет производства за смену».
• Запись в регистры сведений: Данные о температуре со склада или состоянии оборудования записываются в регистры сведений для последующего анализа и построения отчетов.
• Оповещение пользователей: В случае получения критических значений (например, перегрев станка) система может автоматически создавать документ «Событие» или «Задача» для ответственного сотрудника.

Использование RabbitMQ в качестве связующего звена превращает 1С из системы пост-учета в активного участника производственного процесса, обеспечивая надежный, масштабируемый и отказоустойчивый сбор данных для оперативного управления предприятием.

Специалист компании ООО “Кодерлайн”,

Ильичев Иван