Добрый день. 8.3, толстый клиент, клиент-сервер. Снаружи стучатся на HTTP-сервис. По факту стука у определённого клиента в его сеансе должен выполнятся алгоритм. Вопрос - как? Давно не следил за обновлением платформы, может есть что-то быстрое и удобное для этого?

Сервер взаимодействия?

(1) Не понимать вопрос :)

(2) А ты из какой местности, если не секрет?

(0) С сервера к клиенту не обратится никак. Делаешь что бы клиент слал на сервер запросы с необходимой периодичностью (час/минута/секунда). Используй ПодключитьОбработчикОжидания (подробности сам догуглишь). Разумеется все что прилетает на http где то хранишь на сервере, куда клиент и стучится.

К (4). Сервер и клиен, это серверная и клиентская часть 1с.

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

(6) мне тоже. Может я чего пропустил и напишут.

(6) Тебе же написали в (1)

(8) Так я вопрос не понял :)

(0) Внешняя компонента поднимает свой микро http сервер/сервис и если пришел запрос то внешнее событие

(10) ВК работает в сеансе пользователя? Там параллельно есть необходимость распределения событий между пользователями. Сейчас работает так, как предлагали выше - анализируется тело POST-запроса, результат пишется в регистр сведений, который опрашивается пользователи по заданному интервалу. Так как пользователей много (а будет кратно больше) - не хочу тыркать очень часто РС на предмет обновлений (это еще и не очень ОК с точки зрения комфорта работы пользователя), как и редкое обновление тоже. Почему-то думал, что в 1С уже прикрутили чего-нибудь реактивного, с получением данных на лету.

(11) Если сервер и клиентские машины в одной подсети, то через UDP можно. Именно как в (10) сказано ВК - в сеансе пользователя, точнее, даже не в сеансе, а на самой машине пользователя, так как это не сервер, а клиент.

+(12) На краснодарском Infostart Meetup в феврале был доклад на эту тему, даже с кусками кода - копируй и запускай.

(0) А какой результат ожидается, если пользователь откроет под собой два сеанса на одной машине? Ну, например, для ускорения длительных операций (:
Или наоборот, закроет сеанс.

(14) Если два сеанса - то код выполнится в обоих (но на самом деле 99% таких пользователей работают в рамках одного сеанса). Если нет ни одного - то не выполнится вовсе :)

(12) Машины в одной подсети. Остался один последний вопрос - поднимаю в сеансе пользователя ВК, которая слушает UDP. Кто его будет слать? Внешние HTTP запросы по замыслу принимаются сервером 1С совсем снаружи (от стороннего сервиса) и потом по-идее я должен в этом же серверном сеансе постучаться к пользователю? :)

(16) Да, сервер принимает http-запрос и шлет UDP-запрос пользователю.

(15) Я к чему. Схема с регистром и опросом дает тебе бесплатно еще и возможность легко найти необработанные события и обработать их потом или наехать на пользователя. Модный UDP все равно потребует того же самого, плюс две компоненты - на сервере и на каждом клиенте.
Выигрыш только в выносе опроса сервера в отдельный поток и уменьшение серверных вызовов.

(17) Спасибо за идею, будем подумать! :)

(18) Мне история с регистром не нравится только с одного ракурса - притормаживания в сеансе пользователя. Там теоретические коротенький РС должен быть, длиной n*m, где n - количество юзеров,а m - число оповещений, не более 5 на первый взгляд.

(17) Зачем udp когда сервер и другие клиенты могут штатно httpсоединение без ВК

(18) И хотелось бы реакции системы максимально быстрой с момента поступления HTTP запроса ко мне на веб-сервер :)

Самое интересное что в 1С уже изначально встроен механизм "сообщений с сервера на клиент".
Это банальная отладка - debug.

ПодключитьОбработчикОповещения(<ИмяПроцедуры>)
И оповещай всех пользователей как закончишь свой ХТТП запрос обрабатывать.

(23) там передача в конфигуратор операций и с клиента и с сервера,опять же,принимающая сторона-конфигуратор.

если оповещение нужно не мгновенно,то с регистром нормально,только нужно регистр наличия сообщений для сеансов,который они будут дергать все время,отдельно от регистра с данными сообщения,где будут хранится только сообщения,которые еще не обработаны.

(25) и обратно передача тоже, потому что команды понимает продолжить отладку и т.д.
и да отладку через http настраивал?