Добавить возможность уведомлять 1С о приходе сообщения через HTTP сервис

[biterp]

Добавить возможность уведомлять 1С о приходе сообщения через HTTP сервис

[dobromyslov]

Я считаю, что добавлять это в текущую библиотеку - плохая идея. Если нужно будить 1С по HTTP - каждый сам может написать микросервис на любом языке, подписать его на очередь RabbitMQ и делать всё, что угодно с 1С через HTTP. А PinkRabbitMQ должна работать исключительно с RabbitMQ и не более того.

[ripreal]

Идея интересная. Я попробую ее реализовать. Конечно есть и именусы такого подхода:

• необходимость модифицировать метаданные 1С.
• http намного медленее работает чем прямой вызов сообщения компоненты

[MinimaJack]

Можно описание подробнее, не у всех есть доступ к форуму...

[Begemoth2]

@MinimaJack
Цитирую предложение с партнерского форума
"Вы не рассматривали написание прослойки для обмена вашей компоненты с 1С через её http-сервисы (вместо пулинга очереди в цикле)? Например, компонента поднимает прокси и начинает слушать кроля с одной стороны и общаться с 1С с другой (или использовать её http-сервис как push-уведомление)."

[MinimaJack]

Спасибо.
Идея так себе - теряется смысл в компоненте, так можно и сообщения push-ить в сервис из прослойки.

[Begemoth2]

@MinimaJack Нет не теряется, http работает медленнее AMQP (и медленная установка соединения), т.е. тут предложение именно в том, чтобы использовать http-сервис только для того, чтобы "разбудить" 1С (сказать ей что пришли сообщения), а дальше 1С уже через компоненту по протоколу AMQP начинает их массово и параллельно забирать (а отправка так и остается через компоненту).

Т.е. это всего-лишь средство не держать в 1С все время активное соединение которое слушает кролика, а "будить" 1С по внешнему событию

[MinimaJack]

@Begemoth2 Что делать если будет приходить много сообщений?? Спамить 1С вызовами? Как контролировать что данные из очереди все еще забираются регл.заданием? Что делать тем у кого все на поддержке?Кто будет мониторить http-демон? Зачемммм....

Установка соединения что http, что amqp - практически идентична, большая часть времени сожрет tcp-layer.
Весь смысл в backpressure и pull-подходе, когда данные забираются с той скоростью с которой могут быть обработаны. А так получится дикая смесь: ни то, ни сё.

p.s. Текущие сервера без особых проблем переваривают поддержание десятки тысяч активных соединений.
p.p.s Как по мне решается надуманная проблема...

[Begemoth2]

@MinimaJack При текущем подходе (который реализован в компоненте) для того, чтобы новые сообщения приходили быстро (сразу после появления в очереди) на сервере 1С должен постоянно висеть сеанс (например фонового задания) в котором выполняется ожидание в методе BasicConsumeMessage (как только сообщение приходит, оно получается и управление передается в код 1С).

Этот подход (вечно висящее соединение) приводит к определенным проблемам, как минимум конфигурацию сложно обновлять ;-)

Тут речь о том, как можно эту проблему обойти. Понятно, что предложенный подход не идеальный (и мы пока так делать не планируем), но задачу записали (как возможные вариант решения)

[salsa-dev]

@dobromyslov прав, можно сделать свою реализацию сервиса, который будет уведомлять или даже передавать сообщения из системы очередей в 1С.

Если кому известны такие решения, интересно ознакомиться.

В целом, подход PULL обоснован, но, как всегда, есть пограничные случаи, когда PUSH очень нужен.

[salsa-dev]

Нашёл возможное решение https://docs.celeryproject.org/en/latest/getting-started/first-steps-with-celery.html#first-steps

[ripreal]

Не актуально в рамках компоненты. Закрываю