Rabbitmq что это 1с

Обновлено: 08.01.2025

1. Схема выгрузки объектов из базы – источника

1. Для регистрации объектов, подлежащих выгрузки, используем План обмена; собственно, регистрация производится по какому-либо правилу бизнес-процесса, например, при сохранении изменения объекта 1С.

2. Инициализацию выгрузки объектов поручим регламентному заданию; в его обработчике:

2.1. формируем единый для всей выгрузки объектов xdto-контейнер;

2.2. начинаем транзакцию (помимо своей основной функции, она понадобится для снятия управляемых блокировок);

2.3. для каждого вида объекта метаданных вызываем свои процедуры выгрузки объектов, в которых:

2.3.1. из Плана обмена читаем объекты, подлежащие выгрузке;

2.3.2. устанавливаем на эти объекты управляемую блокировку;

2.3.3. на основании xdto-пакета преобразуем объект 1С в объект xdto;

2.3.4. добавляем xdto-объект в единый xdto-контейнер;

2.4. Полученный xdto-контейнер сериализуем в JSON-строку;

2.6. Для выгруженных объектов 1С снимаем регистрацию в Плане обмена;

2.7. Фиксируем транзакцию и снимаем управляемые блокировки.

Если объем выгружаемой информации велик, а база активно используется пользователями, то следует позаботиться об уменьшении времени управляемых блокировок. Идти можно следующими путями:

· локализовать транзакции до выгрузки отдельных видов объектов метаданных;

· разделить выгрузку отдельных видов метаданных на порции, например, по 100 объектов;

· отдельно для каждой такой порции устанавливать транзакции и блокировки.

Схема выгрузки объектов из базы источника

2. Схема загрузки объектов в базе – приемнике

Схема загрузки объектов в базу-приемник

1. За инициализацию загрузки объектов отвечает Регламентное задание; в его обработчике:

1.3.1. На основании xdto-пакетов преобразуем JSON-строки в xdto-объекты;

1.3.2. Преобразуем xdto-объекты в объекты 1С;

1.3.3. Сохраняем объекты 1С в базе 1С.

Результатом является запись в базе-приемнике объектов 1С переданных из баз-источников.

Я не буду вдаваться в подробности установки RabbitMQ, в статье используется Docker контейнер с официального сайта для экспериментов, устанавливается просто:

В качестве модели данных будем использовать Клиента, с полями: ID, Name, Type и Email данную структуру мы будем забирать из шины и помещать в очередь. Данные будут переобразованны в JSON.

Для REST API создадим обработчик exchange_rabbitmq, который будет принимать GET и POST запросы.

Для метода POST получает JSON строку с массивом структур, полученные данные помещаем в шину. Для метода GET получаем данные из шины и передаем их на сторону 1С.

В 1С создадим внешнюю обработку с таблицей, в которую для метода GET будут поступать записи, а для метода POST из таблицы данные будут поступать в шину, как уже говорилось ранее через JSON

Помещаем в шину

Потребляем из шины

Для middleware предусмотрена возможность сохранять настройки подключения к шине

В крации внутри middleware создается метод обрабатывающий запросы на адрес "/rabbitMQ_1C", в зависимости от метода происходит или отправка или потребление, для наглядности поазываю урезанную функцию

Внутри middleware разварачивается по сути небольшой веб-сервис обрабатывающий запросы, своего рода микросервис, в следующих статьях я расскажу как поместить его в Докер контейнр, а также разместить этот контейнер в Докер Хаб

Исходники я разместил на GitHub. Можете использовать исходник как шаблон, жду ваших идей и советов. Ни на что не претендую интересная тема, решил поделиться с сообществом своими наработками. Есть наработки по выгрузке журнала регистраций в ElasticSearch возможно дополню проект новым обработчиком для этого дела.

Интеграция 1С с любыми системами: другими программами 1С, сайтом, банками, CRM, сторонними программами.

Всегда актуальная информация на сайте. Интеграция с любыми CMS: Битрикс, UMI, WordPress, Joomla, Drupal, Tilda и другие.

Понятия «правильной интеграции» в отрыве от конкретной ситуации просто не существует, поэтому от этого определений лучше отказаться и заменить его интеграцией событийной – эффективной интеграцией, удовлетворяющей требования отдельно взятого проекта. Мы рассмотрим инструменты крупных интеграционных проектов, где требовался регулярный обмен большим количеством информации. Именно такие проекты ставят перед интеграторами самые сложные задачи, а как их решить – проиллюстрируем на реальном примере.

Инструменты интеграции

Рассмотрим популярнейшие инструменты интеграции на «эволюционной» шкале, отображающей тот порядок, как их осваивают программисты-разработчики.

XLS, CSV

Простейший вариант для несложных интеграций, например, для загрузки табличного документа. Структуру данный формат не поддерживает, в файле может быть только одна таблица или только одна вкладка, а о том, что нельзя настроить связи между несколькими таблицами, даже упоминать не стоит. По этим причинам настраивать интеграцию посредством XLS, CSV придется каждый раз как в первый: один документ-Excel загрузился, но следующий будет иметь другую структуру или даже другой формат (xls, xlsx; csv – может «возникнуть» запятая, точка с запятой или табуляция), поэтому предыдущая настройка не сработает.

COM-коннектор

У данного инструмента интеграции серьезный минус – он разработан под Windows. Когда технологии Linux захватывают все большие объемы рынка, а серверов на Windows становится все меньше (остаются по большому счету только терминальные), W-интеграции все менее применимы на проектах.

Помимо этого COM-коннектор дает «полную свободу действий». Этому радуются разработчики, но не жалуют представители служб безопасности, поскольку 1С не поддерживает передачу хэша при передаче пароля и ком-коннектор передает его в открытом виде.

XML и JSON

Данный инструмент можно назвать продвинутым: поддерживается структура, передаются массивы, штатные функции. Но работа с XML и JSON подразумевает работу с простыми файлами, выгрузка которых при постоянной интеграции требует транспорта, протокола, инфраструктуры и т.д. То есть их нужно версионировать, передать, убедиться, что файл ушел и принимающая система его загрузила… Поэтому любая ошибка здесь чревата потерями и расхождениями данных.

Конвертация 2.0, 2.1

Подходящий механизм для постановки интеграции в масштабах проекта, поддерживающий обмены по расписанию, настройки, правила регистрации и т.д. Но как раз в обмене по расписанию и заложены определенные ограничения: если обмен происходит, например, один раз в секунду, то система будет перегружена, если один раз в 20 минут – возникают проблемы с актуальностью. Также работа с данными при таком обмене чревата возникновением коллизий.

Но это еще не все. Даже задав правила конвертации и выгрузки, проставив реквизиты, можно столкнуться с проблемой логирования и отладки на вкладке «Алгоритмы», которая представляет собой, по сути, массивные куски кода. Если выгрузка происходит, но как-то не так, нужно отлаживать конвертацию. При этом искать ошибку в гигабайтном xml-файле, когда регистрация уже потерта, потому что бизнесу надо работать, – все равно что искать иголку в стоге сена.

Решением этих проблем может стать интеграционная шина.

Событийная интеграция и интеграционная шина

Основной плюс данной технологии – возможность настроить интеграцию единожды благодаря шине-посреднику.

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

Архитектура и инструментарий

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

Почему пример «плохой»? Подобная схема может работать даже на крупных проектах, но назвать ее оптимальной нельзя.

Рассмотрим «хороший» пример:

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

MuleESB

Mule ESB имеет OpenSource-версию, что определенно является преимуществом. Enterprise-версия, которая при необходимости кластеризуется, имеет удобный веб-интерфейс. В MarketPlace для MuleESB найдется интеграция с огромным количеством разных систем, что может упростить работу в десятки раз.

RabbitMQ

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

Elastic

SoapUI – удобный инструмент отладки Soap-запросов и не только, с возможностью чтения SDL и их отладки. Позволяет сделать Soap-сервер и отладить его, сделав в SoapUI заглушку в SDL.

Enterprise Data – данный инструмент приближает 1С к принципам событийной интеграции.

Механизм Incorporate предусматривает использование интеграционной шины, причем не только для внешней интеграции. Для типовых прикладных решений, в которых Enterprise Data уже встроена, такая схема интеграции упростит процесс в несколько десятков раз, несмотря на значительное количество проблемных моментов.

В больших компаниях и холдингах не редкое явление встретить огромное количество интеграционных потоков. Бывают ситуации, когда эти потоки делались по факту потребности и на скорую руку. Решением для возможности управления такими потоками являются сервисы (службы или брокеры) обмена.

Некоторые плюсы использования единого сервера обмена:

Один или несколько стандартных протоколов обмена данными;
Возможность построить карту маршрутов передаваемых данных.

Немного о предоставляемой CloudAMQP бесплатной услуге (тарифный план Little Lemur)

If queues gets longer than that, messages will be dropped from the beginning of the queue. Dedicated plans does not have this limitation.

Библиотека RabbitMQ Client для DotNet:

Сама библиотека (v5) доступна в репозитории

Можно установить через стандартные менеджеры пактов NuGet или DotNet;

Можно скачать оба пакета NuPkg, извлечь нужные DLL и зарегистрировать в windows через RegAsm.exe:

Для корректной регистрации RabbitMQ.Client.dll через RegAsm, файл Microsoft.Diagnostics.Tracing.EventSource.dll должен быть в той-же папке.

Снимок экрана использования RegAam.exe

Реализация программного кода 1С с подробными комментариями:
(код описанный ниже, теоретический может быть переписан под любой язык программирования поддерживающий работу с COM объектами, так как по сути вызывает стандартные методы библиотеки RabbitMQ.Client.dll, ОписаниеAPI)

Описание общих этапов алгоритма:

Реализация полностью OpenSource;
Нет никакого платного либо самописного коннектора;
Можно использовать и обновлять официальную библиотеку RabbitMQ.Client.dll.

Описание дополнительных способов кодирования и декодирования:

Но тогда мы ограничиваем себя исключительно кодировкой UTF-8.

Еще можно использовать стандартные возможности платформы "Символ()" и "КодСимвола()", для сборки и разборки COMSafeArray. Но тогда мы ограничимся символами чей код не более 255 (как бы ASCII получается), потому что массив типа "VT_UI1" имеет однобайтовые ячейки.

Читайте также: