search

BITERP / PinkRabbitMQ

Внешняя Native API компонента для взаимодействия с RabbitMQ из 1С
MIT License
264 stars 107 forks source link

Добавить работу с headers сообщения #46

Open avdunaev1 opened 3 years ago

avdunaev1 commented 3 years ago

Добрый день! Компонента сейчас предоставляет доступ к свойствам сообщения (MessageId, ContentType и пр.), но не к Headers. Можно ли добавить такую возможность? Это было бы полезно, например, при приеме сообщений MQTT через Rabbit.

IsakovArtem commented 3 years ago

Добрый день.

Поддерживаю, Headers очень нужны. Только отсутствие Headers препятствует переходу на "PinkRabbitMQ". Очень жду этой доработки.

Спасибо!

Begemoth2 commented 3 years ago

@avdunaev1 @IsakovArtem Опишите подробнее зачем/как вы планируете использовать headers и чем не подходят "стандартные" свойства сообщений? Мы тоже используем компоненту для работы с MQTT через Rabbit (для получения марок с производственной линии) и вроде нам headers пока не требуются

avdunaev1 commented 3 years ago

@Begemoth2

Например, я бы хотел передавать через Headers какую-то расширенную информацию об отправителе, чтобы она была доступна до чтения JSON самого сообщения. Наверное, можно выкрутиться и "закодировать" эту инфу, используя "стандартные" свойства, имена обменников, очередей и ключей, но это не всегда удобно.

Если говорить именно о MQTT, то при просмотре MQTT-сообщений в веб-интерфейсе RabbitMQ я вижу, например, в headers параметр x-mqtt-publish-qos = 1. Он был бы мне интересен. Но в 1С с помощью компоненты я до него добраться не могу.

Может быть, есть еще какие-то пути решения, имеющимися средствами? Вам при передаче марок не приходится передавать какую-то доп. информацию о сообщении, которая не укладывается в стандартные свойства?

Begemoth2 commented 3 years ago

@avdunaev1

чтобы она была доступна до чтения JSON самого сообщения

А почему это для вас важно? Т.е. почему для вашей задачи важно получить информацию из заголовков, а не из тела сообщения (ведь для этого по факту вы все равно получите сообщение на клиента)?

Вам при передаче марок не приходится передавать какую-то доп. информацию о сообщении, которая не укладывается в стандартные свойства?

Мы передаем все в теле сообщения, т.е. даже "простой контролер" справляется с тем чтобы засунуть информацию о марке (причем в base64) и дате/месте события в json

avdunaev1 commented 3 years ago

А почему это для вас важно? Т.е. почему для вашей задачи важно получить информацию из заголовков, а не из тела сообщения (ведь для этого по факту вы все равно получите сообщение на клиента)?

Может потребоваться, что сообщение сначала получается из рэббита и сохраняется в 1С, а обрабатывается позже. Причем после записи могут потребоваться какие-то служебные действия (отправить подтверждение приема в зависимости от QoS или назначить приоритет обработки в зависимости от отправителя). В этом случае потребуется читать JSON два раза. Один раз при получении сообщения из рэббита, чтобы определить параметры, а потом собственно для основной обработки сообщения. А если, например, сообщение по каким-то причинам не удается разобрать? Например, хранящаяся в 1С XSD-схема для этого типа сообщений устарела? Если у меня будут заголовки я буду знать, что "внешняя система 1" прислала сообщение, которое не удалось прочитать. А без заголовков у меня будет просто непонятное сообщение неизвестно от кого.

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

gstalnoy commented 3 years ago

@avdunaev1 @IsakovArtem поскольку описанная задача не связана с устранением критической уязвимости, то остается 3 пути, как запрошенные вами доработки могут быть выполнены в компоненте:

  1. кому-то из покупателей/подписчиков БИТ.Адаптер потребуется данный функционал
  2. одной из команд БИТ:ERP потребуется данный функционал (тиражные БИТ.MDT, БИТ.IIoT или на проекте)
  3. ждем ваших пул-риквестов (с) :)
avdunaev1 commented 3 years ago

@gstalnoy Глеб, спасибо за ответ. Посмотрим, какой из этих 3 вариантов сработает первым... :)