1С и Apache kafka

Внешняя компонента для интеграции 1С и Apache kafka удобным способом. Компонента работает под windows и linux. Основная логика написана на Rust, что сильно снижает риск утечек памяти. Есть бесплатная и платная версии.

🎞Видео обзор

Скачать можно по 🔗ссылке

1С и RabbitMQ

Внешняя компонента для интеграции 1С и RabbitMQ удобным способом. Компонента работает под windows и linux. Основная логика написана на Rust, что сильно снижает риск утечек памяти. Есть бесплатная и платная версии.

🎞Видео обзор

Скачать можно 🔗по ссылке

1С и Apache kafka

Новая версия 0.9.1

Добавлена возможность указывать таймаут при получении сообщения. Если в течении этого таймаута не появится сообщение в топике, ожидание в функции
Сообщение = КлиентKafka.ПолучитьСообщение(Канал);
прервется.

Таймаут = 30;//сек. 
КонфигурацияПотребителя = КлиентKafka.КонфигурацияПотребителя(Топик, Теги, Таймаут);
Канал = КлиентKafka.НачатьПолучениеСообщений(КонфигурацияПотребителя);
Сообщение = КлиентKafka.ПолучитьСообщение(Канал);

🎞Первый видео обзор

Скачать можно 🔗по ссылке

1С и RabbitMQ
Новая версия 0.9.6

Добавлена возможность прерывать ожидание нового сообщения из очереди. Так как ожидание в функции КлиентRMQ.СледующееСообщение(Получатель) это блокирующее ожидание, т.к. оно блокирует поток выполнения 1С до момента когда в очереди появится сообщение, а иногда необходимо прервать ожидание, то можно использовать пару методов:
1. КлиентRMQ.ПолучитьСписокПолучателейСообщений() который вернет массив всех получателей и
2. КлиентRMQ.ОстановитьОжиданиеСообщения(Получение). Так же это можно делать интерактивно, через интерфейс обработки КлиентRMQ, там же можно посмотреть как это работает, для программного прерывания ожидания сообщения.

Подробнее 🎞в видео в комментарии

🔗Скачать

🎞Первый видео обзор

1С и Apache kafka

Новая версия 0.9.2

Добавлен метод ДобавитьТопикРазделИСмещение() для явного указания Топика, раздела и смещения, с которого начать чтение. Пример в демо конфигурации, в обработке ОжиданиеИОбработкаСообщенийСРучнымУправлениемСмещением.

  // Указывается явно с какого раздела и с какого смещения начать читать
  // Если не требуется явно указывать номер раздела и смещение, а надо подписаться на топик полность
  // и смещение будет запоминаться на сервере (через вызов КлиентKafka.СохранитьСмещение(Сообщение))
  // то можно не исползовать этот метод, а указать топик в  КлиентKafka.КонфигурацияПотребителя(Топик)
  // Если топик указан через ДобавитьТопикРазделИСмещение, то настройки топика в КлиентKafka.КонфигурацияПотребителя(Топик) будет игнорироваться
  КлиентKafka.ДобавитьТопикРазделИСмещение(КонфигурацияПотребителя, "1CRefs", 0, 2);

🔗Скачать

1С и RabbitMQ
Новая версия 0.9.7
Исправлена ошибка подключения компоненты в linux

1С и RabbitMQ

Добавлена возможность использовать стандартные свойства сообщения (которые определяются самим протоколом AMQP):
content_type, content_encoding, priority, correlation_id, reply_to, expiration, message_id, timestamp, type, user_id, app_id, cluster_id. Пример использования этих свойств в обработке ИспользованиеСвойствСообщений.

Один из сценариев использования этих свойств — это реализация RPC через брокеры сообщений.

Общая концепция реализации RPC через RabbitMQ:
Предположим, что есть клиент и сервер; необходимо вызвать удаленные процедуры с клиента на сервере и вернуть результат (RPC).

1. Создается очередь, например, rpc_queue, в которую будут поступать запросы от клиента и которую будет прослушивать сервер.
2. Клиент отправляет запрос в эту очередь, например, для выполнения какого-либо расчета.
3. В сообщение клиент добавляет свойство reply_to с названием очереди, в которую сервер должен отправить ответ.
4. После отправки запроса клиент прослушивает очередь, указанную в свойстве reply_to.
5. Сервер, получив сообщение с запросом из очереди rpc_queue, обрабатывает его и отправляет ответ в очередь, указанную в свойстве reply_to (указанную клиентом).
6. Клиент получает ответ и обрабатывает его соответствующим образом.

Если необходимо связать запрос и ответ, то клиент может так же указать УИД запроса в свойстве correlation_id, сервер в ответном сообщение скопирует это свойство, таким образом клиет будет знать на какой именно запрос ему ответил сервер.

Заполнение и работа со свойствами на стороне клиента и сервера реализуется вручную, RMQ не вмешивается в этот процесс, он на уровне протокола AMQP предоставляет готовые свойства. Но есть свойства которые обрабатывает RMQ, н.п. если указать время жизни в свойстве expiration, то по истечении этого времени RMQ удалить сообщение из очереди.

🔗Скачать новую версию

Общую концепцию так же можно почитать в туториале на сайте rmq