На уровне компоненты используют "нормальное" API. Как раз push.
Как это потом клиенту отдается - другой вопрос.
Как это потом клиенту отдается - другой вопрос.
Size: a a a
2021 June 08
NG
Вообще rpc на рэббите можно организовать и в пульской компоненте и в первобитовской. Но по своему опыту - лучше отказаться от этого решения так, как оно сделано в пульской подсистеме - очень неудобно работать с вечно зависшим сеансом. Лучше просто сделать две очереди - запрос и ответ, чтобы сайт слал message id в пропертях, а 1с по этому же id слала ответ
AO
Я был молод и мне нужны были деньги.
NG
На колбэках - нет, нельзя
OT
Учитывая что базовое API у компонент одинаковое.
AO
Это не то, чтоб идеальный рпс это вообще первый рпс для кролико1С. Будьте снисходительны
NG
У компонент - одинаковое. Я про подсистему для 1с
NG
Он хорош в целом. Просто именно мне не подошёл :)
D
Ну то есть получается не особо-то это событийная интеграция если всё равно нужно запускать регламентное по расписанию чтобы прочитать новые сообщения?
AO
Нет, будем честны, он так себе. Слишком большое трение по использованию
of
https://cloud.yandex.ru/docs/message-queue/ стырено естессно у амазона. MQ с http интерфейсом и без заботы об инфраструктуре. Проверял на уровне тестов, мне понравилось... Мне кажется рабочий концепт надо рассмартивать именно такой...
Да нормальная там компонента)
AO
Я про именно RPC протокол на стороне 1С-ной части
AO
А компонента там огонь, чо
NG
Они висят постоянно. Под каждую очередь висит регл задание и ждёт сообщение в сокете с таймаутом. Пример с basic consume message неполный, он может висеть и ждать сообщения сколько угодно, а не только сразу завершать свое выполнение
AO
Один пайплайн сборки чего стоит
Где-то тут должно быть упоминание шины от вендора)
AO
Ее не существует
шина Шредингера