Как можно оповещать клиента о событии на сервере?

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

А зачем оповещать? что хотите добиться?

(4) процентов на 80 думаю что хрень

(2) 1с:Диалог..

(4) сохранить куда-то инфу о сообщении на сервере, а с клиента периодически ее считывать (обработчиком ожидания, например). Куда зависит от целей, где-то лучше РС, где-то параметра сеанса довольно

Задачу создать.

(0) подключай в клиенте обработчик ожидания. ну а на сервере проверяй есть ли событие и отправляй ответ. Можно и без регистра. Через параметр сеанса какой там.

или через сохраненное значение, которое живет пока открыта форма.
Можешь в константу пихать, как вариант, очередь событий.

если базу напрягает дергать - юзай файловый флаг

(10) А задачи РС дёргать не будут )))

(0) http://1clancer.ru/catalog/4336

есть 3 основных механизма передачи между не связанными сеансами

1. блокировка, один сеанс блокирует определенный объект (например элемент справочника), метод хорош тем, что не требуется чего либо записывать и в случае аварийного завершения мастер сеанса блокировка автоматически снимается (нет проблем с фантомами).
2. запись события (или задачи, или регистр сведений или константа),
3. NET обмен (сюда входят и сервер взаимодействия и всякие DLL), то есть то, что напрямую дает общение сервер>клиент.

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

(17) Переходите на fb/ib, там оно из коробки. Триггер СУБД может оправить уведомление, которое вызывает срабатывание триггера на клиенте. А в 1с жосткий интерпрайз, и держать постоянно открытое соединение сейчас не модно.

(18) > держать постоянно открытое соединение сейчас не модно
Как это не модно? А веб-сокеты разве не так работают?

(19) именно так,только соединение держится со специальным сервером,который или у дяди или покупать надо.
Они бы хоть асинхронный http-запрос реализовали бы,а то приходится в поле html-дркумента костыли набивать.

А так да, interbase от рождения умел посылать события с сервера на клиента,то есть в хранимой процедуре посылаешь событие,и опа,его уже все получили. Поэтому,на нем все системы безопасности делались,и,например,перевод на MySql стоил немалых усилий и костылей,так как последний "честный" sql-сервер и события на клиента слать не умеет.

(17)А если у тебя почтальон не знает района и не ходит по домам? Тогда остается только клиенту ходить на почту периодически.

(9) не проблема, как-бэ. Делал подобную задачу. И да, а кто сказал что нужно раз в 3 сек? Раз в 15 - вполне будет норм.

(23) у меня параллельные фончики раз в десять секунд опрашивались,и ничего,все работало как часы.
В web-технологиях,задержка в районе 10 секунд вообще задержкой не считается.
Конечно,бывают процессы,когда нужно сразу,например,после сканирования сканером штрих-кода хочется,чтобы окно с информацией о товаре выразило быстрее секунды,но,слава богу,сканер и не на сервере.

Оповещай через web сервис. Задержки никакой, и сервер опрашивать не надо.

(9) "Но представь, что десяток пользователей будут каждые 3 секунды делать запрос к нему."

Ну ты попробуй сделать прототип. Что то не видится проблемы. Там ведь не будет выборок больших.

я как то подобный вопрос задавал Использование веб-сервиса для опроса с регулярной высокой периодичностью

(26) У меня реализован твариант с РС.  Сейчас передлываю на сервер взаимодействия

(28) ниче не понятно, что именно сделал, почему переделываешь, какая нагрузка

(25) Оповещать клиента 1С через веб сервис? Это как? :)
(26) Аналогично не вижу проблемы. Тоже мне нагрузка.
ЗЫ. Если в рамках локалки - то есть ВК, поднимающие TCP-сервер на клиенте.

(24) У меня на рабочем месте охраны производится раз в 1 сек проверка на новые записи в талицы взвешивания (весы для грузовиков на въезде-выезде), успевает, но это 1 рабочее место и требуется сверхоперативно, а вот когда юзеров дофига и нет никакой причины в сверхоперативном оповещении - 15-20 сек в самый раз (для эстетов, при переходе в окно оповещения можно сделать чаще обновление, например 3 сек - это вполне разумно)

(2) а за что надо платить 50 тыс. рублей? сервис платный стал что ль?

(32) для сервиса нужна лицензия корп

(33) тогда можно свой сервер взаимодействия поднять. В любом случае это лучше, чем в режиме Осла из Шрэка дергать ежесекундно (как в (31) ) сервер с вопросом "Готово?"

(34) поднимай Алексей, разве кто-то против... Вот только топикстартеру наверное рановато

(9) А время реакции юзера какое? Вот прям всё бросит и в течение 3 секунд побежит реагировать! А если он чай пьёт? Ни к чему 3 сек.

(34) кста, если что дёргаю сиквел... Ему не сложно ибо это его планида

(37) ну дергаете то вы еще и регистр, иначе как вам инкрементные записи в сиквеле получить. Плюс время на соединение с СУБД. И всё это в интервале 1 сек...

(38) проверено: не напрягает, успевает.
Да и сколько там записей то... За день пару сотен новых лишь(примерно)

(29) РС прекрасно работает, когда при отправке оповещения с сервере известны ВСЕ конечные получатели. У меня увы, сложилась ситуация, что известен только объект, по которому на сервере произошло событие, а получатели - неизвестны. Соотвественно нет понимания, когда мне из РС убирать запись о произошедшем событии. Я извернулся, установив время жизни события в 30 секунд, но результатом получил проблему, что какой-то получатель за 30 секунд не прочитал запись, и как следствие не получил уведомление о событии.
Вот по этой причине сейчас перенелываю на работу с сервером взаимодействия.

(40) Странная причина. Почему не чистить, скажем, еженедельным регламентом? В чем срочность сразу "хвосты заносить"?

(40) "Получатели неизвестны" - это как?
А как определяется, получит пользователь сообщение или нет?

(41) (42) Если отбросить просто кривую реализацию архитектуры разработчиком (отраслевка 1с), то примерно ситуация такая: есть некий документ, есть некоторые рабочие места, которые через арм вносят изменения в этот документ. При этом арм может быть открыт на произвольном количестве мест. При изменении данных в арм, эти изменения вносятся в документ. Задача - опевестить все армы об изменениях и заставить обновиться в части внесенных изменений.

(42) мне фактически нужен некий аналог в 1с межсеансовой (между клиентами и с сервера на клиент) широковещалки типа UDP, а не TCP

(0) (40) Для оповещений есть много отличного специализированного софта, не обязательно заставлять это делать 1С.
Очереди сообщений всякие, даже простой веб-сервер с пушем справится.

(43) Если много пользователей одновременно редактируют один документ, — это действительно кривая архитектура.

(45) Я ещё могу представить, для чего это может быть нужно, но почему это именно так реализовано? О_о

(44) http://1clancer.ru/catalog/4336
Вот неплохая широковещался как на TCP, так и на UDP

(9) Разве сервер 1С не кэширует результаты одинаковых запросов? Выполняется только первый если таблица не менялась.
(41) Зачем убирать? Записывай время возникновения события в миллисекундах типа guid, а на клиенте параметр заведи - последнее считанное событие. И в запросе бери то что ещё не читал.

(48) пасип
(49) да вариантов куча. просто тут уже пошли путем к правильной архитектуре

можно еще посмотреть в сторону как в типовых напоминания по задачам выполняются в бизнес процессах

(50) Я не уверен, что вы пошли к правильной архитектуре. Мне не нравится система взаимодействий. Как продукт (концепция-то верная).
Использовать внешний сервис для внутренних уведомлений являющихся частью бизнес-логики - это быть ССЗБ.
Ставить свой - дорого. Да и сопровождать этот драндулет с кучей всего на борту чего не надо для этой задачи не хочется.
Я бы делал как выше предложили - на РС с таймстемпами. Если надо что-то типа уведомления о входящем звонке (которое должно быть мгновенно) - ВК с TCP-сервером.
Если корпоративные чаты и т.п. - так и быть, система взаимодействий. Но использовать систему взаимодействий в качестве чего-то, что сломавшись положит оперативную работу - я бы не рискнул.
На инфостарте, например, видел ветку когда у чела СВ тормозить начала как не в себя а в чем дело - понять не могут.

Все ждали от 1С простого сервиса в составе кластера для простых серверных пушей, а они вместо этого выкатили китайскую чуду-юду - фонарик с радио на борту.

(53) +100
Ради простейшей вещи: уведомлений клиента с сервера, надо городить серверы, сервисы и прочие огороды.

(0) А задачу нельзя генерировать?

Система взаимодействия - это пятое колесо в телеге,особенно,если внешняя.
Если внутренняя,то ее нужно покупать,и платить дофига бабла для обмена только в 1с,как бы,глупо.
А внешняя,это соединение в интернет с прокси и т.п.,что отрицательно сказывается на быстроте ее работы,ну и дыра в безопасности,само собой.
Поэтому,свой сервер с уведомлениями через push,и радоваться.
А для 1с можно и нажималку кнопки сделать через mshta и autoit даже не вникая в программирование.