Про удавов, питонов и кроликов. «Серебряная Пуля» выпустила новый релиз Yellow RabbitMQ 1.8.0

yrmq

#1

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

Yellow RabbitMQ («Кролик») – продукт «Серебряной Пули» для «1С» на базе RabbitMQ – платформы для обмена сообщениями между компонентами программной системы. Это новый, быстрый сервис интеграции информационных систем и программных продуктов для любого бизнеса (обмена данными между системами с возможной последующей их обработкой).

Многие предприятия уже успешно решают с помощью адаптера Yellow RabbitMQ различные интеграционные и сопутствующие задачи. Среди них сельскохозяйственный холдинг «Агрокомплекс», дистрибьютор автозапчастей ROSSKO, франчайзи «1С» - компания «Первый БИТ», сеть электроники и бытовой техники «Технодом» и другие.

В новой версии продукта реализован ряд методов и правил, внесены необходимые дополнения и корректировки, в том числе реализована поддержка сжатых каналов связи ( gzip ) для интеграции с популярными приложениями на Python.

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

При этом популярные AMQP* клиенты языка Python активно используют сжатие сообщений, пересылаемых через RabbitMQ. В «1С» сжатые данные попадают в сильно искаженном виде. Для того, чтобы этого не происходило, в версии 1.8.0 Yellow RabbitMQ существенно упрощена интеграция «1С» с такими приложениями и обеспечено получение корректных данных в несколько кликов. Другими словами, реализована поддержка сжатия данных, обеспечивающая интеграцию «из коробки» с такими фреймворками**, как Django, и прочими корпоративными приложениями на Python.

*AMQP (Advanced Message Queuing Protocol) - открытый протокол для передачи сообщений между компонентами системы.
**Веб-фреймворк - инструмент, облегчающий процесс написания и запуска веб-приложения.


#2

Только у меня свойство timestamp перестало передаваться? Причем в свойстве компоненты в отладчике реквизит заполнен, но в исходящем сообщении = 0.
Также вопрос - в чем смысл указывать время жизни в типе строка?
В догонку - при вызове метода Клиент.SetProperty(ИмяСвойства, Значение) иногда получаем - “Некорректная работа компоненты с памятью”. Если использовать Клиент[ИмяСвойства] = Значение, то проблем нет.


#3

Также не работает передача идентификатора таблицы аргументов в метод DeclareExchange.


#4

Пока могу сказать что все тесты проходят ;-).

@EvilBeaver @Infactum - поглядим ?

@RomDron - на всякий случай напомню: пишите сразу на help@silverbulleters.org - тогда хотфиксы если они необходимы будут выпускаться быстрей.

Иногда ???


#5

Иногда - это на третий/четвертый последовательный вызов… :slight_smile:


#6

Принято, посмотрим.


#7

По отметке времени - передаю, например число 1545935859. На версии компоненты 1.3.0.10 проблем с передачей отметки времени не было.

image


#8

У НативАпи были проблемы при передаче таких больших чисел.
Именно 15 с кучей нулей :frowning: как и на скриншоте


#9

передавайте строкой :slight_smile:


#10

смотри выше :slight_smile:


#11

Тип свойства “ОтметкаВремени” компоненты - число. Как его передавать в виде строки?


#12

это обычный unixTimeStamp. И при вводе таких чисел в Веб интерфейсе проблем не возникает. Скорее всего неверный тип переменной хранения значения в компоненте.


#13

@RomDron время жизни строкой - это часть спецификации AMQP: https://www.rabbitmq.com/amqp-0-9-1-reference.html и https://www.rabbitmq.com/ttl.html

А судя по тексту

Since the expiration field must be a string, the broker will (only) accept the string representation of the number.

они и сами не понимают почему оно строка, а не число.


#14

Да, я читал спецификацию. Но возможно в компоненте стоит улучшить этот момент, и передавать число? Причем в методе basicPublish этот параметр и есть число, что удобно. Но пришлось его не использовать, следуя документации.


#15

Думаю стоит поддержать оба типа данных, действительно и для удобства и для совместимости.


#16

[quote=“lustin, post:4, topic:2553, full:true”]

Пока могу сказать что все тесты проходят ;-).

Тесты проходят, так как передачи этого метода в подсистеме просто не предусмотрено. :slight_smile: Соответственно получаем не полное покрытие тестами.


#17

У нас тесты не только на подсистему, но и на саму компоненту. Там свойство Timestamp накрыто тестом отправки и получения из очереди этого свойства. Тест проходит. Сейчас расследуем, что может быть причиной неверного поведения у вас.


#18

Коллеги, релиз 1.8.1 с исправлением ошибок timestamp разослан подписчикам