|
Как можно оповещать клиента о событии на сервере? | ☑ | ||
---|---|---|---|---|
0
RetardedToBoot
04.01.21
✎
01:27
|
Какие есть варианты оповещения клиентской 1с о событии на сервере?
Примеры событий на сервере - пришла команда с ТСД. Или один пользователь сохранил документ, а у другого от этого должна загорется лампочка. То, что можно периодически опрашивать сервер о наличии новых данных, это понятно. Вопрос как лучше сделать это вариант, или может есть лучше? Оптимально, если клиент будет знать о событии не позднее чем через 3 секунды после такового. Но слать запросы на сервер каждые 3 секунды это как то напрягает. |
|||
1
Aleksey
04.01.21
✎
01:42
|
Сервер взаимодействия?
|
|||
2
RetardedToBoot
04.01.21
✎
01:52
|
(1) А есть варианты кроме как заплатить 50тыс?
|
|||
3
Злопчинский
04.01.21
✎
01:53
|
А зачем оповещать? что хотите добиться?
|
|||
4
RetardedToBoot
04.01.21
✎
02:29
|
(3) Заказчик сказал что нужно. Нужно оповещать.
|
|||
5
Злопчинский
04.01.21
✎
02:48
|
(4) процентов на 80 думаю что хрень
|
|||
6
RetardedToBoot
04.01.21
✎
02:54
|
(5) зависит от результата, так же как и слово хрень.
|
|||
7
ДенисЧ
04.01.21
✎
05:27
|
(2) 1с:Диалог..
|
|||
8
rphosts
04.01.21
✎
07:00
|
(4) сохранить куда-то инфу о сообщении на сервере, а с клиента периодически ее считывать (обработчиком ожидания, например). Куда зависит от целей, где-то лучше РС, где-то параметра сеанса довольно
|
|||
9
RetardedToBoot
04.01.21
✎
07:56
|
(8) Сохранение в РС я пока вижу как наипростой вариант из возможностых. Но представь, что десяток пользователей будут каждые 3 секунды делать запрос к нему. А фактически события будут раз в час-два на пользователя.
Второй из возможных методов я предполагаю что можно в 1С создать HTTP-сервис, и на него складывать сообщения, и к нему запрашивать все под одним пользователем. На инфостарте упоминалось о такой возможности. Тогда возможно в параметры сеанса, т.к. при определенных настройках сеанс не умирает сразу (пока не проверял). Ну и третий вариант, это сделать сервер Redis/webdis или что-нибудь еще из подобных, и обращаться уже через него. Но тут нужно мозги совсем поднапрячь. |
|||
10
Alexor
04.01.21
✎
08:06
|
Задачу создать.
|
|||
11
Гений 1С
гуру
04.01.21
✎
08:07
|
(0) подключай в клиенте обработчик ожидания. ну а на сервере проверяй есть ли событие и отправляй ответ. Можно и без регистра. Через параметр сеанса какой там.
|
|||
12
Гений 1С
гуру
04.01.21
✎
08:08
|
или через сохраненное значение, которое живет пока открыта форма.
Можешь в константу пихать, как вариант, очередь событий. |
|||
13
Гений 1С
гуру
04.01.21
✎
08:09
|
если базу напрягает дергать - юзай файловый флаг
|
|||
14
ДенисЧ
04.01.21
✎
08:12
|
(10) А задачи РС дёргать не будут )))
|
|||
15
ДНН
04.01.21
✎
08:13
|
||||
16
vde69
04.01.21
✎
09:47
|
есть 3 основных механизма передачи между не связанными сеансами
1. блокировка, один сеанс блокирует определенный объект (например элемент справочника), метод хорош тем, что не требуется чего либо записывать и в случае аварийного завершения мастер сеанса блокировка автоматически снимается (нет проблем с фантомами). 2. запись события (или задачи, или регистр сведений или константа), 3. NET обмен (сюда входят и сервер взаимодействия и всякие DLL), то есть то, что напрямую дает общение сервер>клиент. |
|||
17
Злопчинский
04.01.21
✎
12:50
|
все херня.
надо как почтальон телеграммы носит. постучался - я открыл - телеграмма. а не так чтобы я каждые 5 минут бегал открывал дверь и смотрел нет ли телеграммы. |
|||
18
Провинциальный 1сник
04.01.21
✎
13:00
|
(17) Переходите на fb/ib, там оно из коробки. Триггер СУБД может оправить уведомление, которое вызывает срабатывание триггера на клиенте. А в 1с жосткий интерпрайз, и держать постоянно открытое соединение сейчас не модно.
|
|||
19
fisher
04.01.21
✎
13:10
|
(18) > держать постоянно открытое соединение сейчас не модно
Как это не модно? А веб-сокеты разве не так работают? |
|||
20
ДедМорроз
04.01.21
✎
17:34
|
(19) именно так,только соединение держится со специальным сервером,который или у дяди или покупать надо.
Они бы хоть асинхронный http-запрос реализовали бы,а то приходится в поле html-дркумента костыли набивать. |
|||
21
ДедМорроз
04.01.21
✎
17:37
|
А так да, interbase от рождения умел посылать события с сервера на клиента,то есть в хранимой процедуре посылаешь событие,и опа,его уже все получили. Поэтому,на нем все системы безопасности делались,и,например,перевод на MySql стоил немалых усилий и костылей,так как последний "честный" sql-сервер и события на клиента слать не умеет.
|
|||
22
Сергиус
04.01.21
✎
19:17
|
(17)А если у тебя почтальон не знает района и не ходит по домам? Тогда остается только клиенту ходить на почту периодически.
|
|||
23
rphosts
04.01.21
✎
19:38
|
(9) не проблема, как-бэ. Делал подобную задачу. И да, а кто сказал что нужно раз в 3 сек? Раз в 15 - вполне будет норм.
|
|||
24
ДедМорроз
04.01.21
✎
19:54
|
(23) у меня параллельные фончики раз в десять секунд опрашивались,и ничего,все работало как часы.
В web-технологиях,задержка в районе 10 секунд вообще задержкой не считается. Конечно,бывают процессы,когда нужно сразу,например,после сканирования сканером штрих-кода хочется,чтобы окно с информацией о товаре выразило быстрее секунды,но,слава богу,сканер и не на сервере. |
|||
25
rowvg
naïve
04.01.21
✎
20:18
|
Оповещай через web сервис. Задержки никакой, и сервер опрашивать не надо.
|
|||
26
vi0
05.01.21
✎
07:31
|
(9) "Но представь, что десяток пользователей будут каждые 3 секунды делать запрос к нему."
Ну ты попробуй сделать прототип. Что то не видится проблемы. Там ведь не будет выборок больших. |
|||
27
vi0
05.01.21
✎
07:40
|
я как то подобный вопрос задавал Использование веб-сервиса для опроса с регулярной высокой периодичностью
|
|||
28
Itmaint
05.01.21
✎
07:50
|
(26) У меня реализован твариант с РС. Сейчас передлываю на сервер взаимодействия
|
|||
29
vi0
05.01.21
✎
07:57
|
(28) ниче не понятно, что именно сделал, почему переделываешь, какая нагрузка
|
|||
30
fisher
05.01.21
✎
10:10
|
(25) Оповещать клиента 1С через веб сервис? Это как? :)
(26) Аналогично не вижу проблемы. Тоже мне нагрузка. ЗЫ. Если в рамках локалки - то есть ВК, поднимающие TCP-сервер на клиенте. |
|||
31
rphosts
05.01.21
✎
10:17
|
(24) У меня на рабочем месте охраны производится раз в 1 сек проверка на новые записи в талицы взвешивания (весы для грузовиков на въезде-выезде), успевает, но это 1 рабочее место и требуется сверхоперативно, а вот когда юзеров дофига и нет никакой причины в сверхоперативном оповещении - 15-20 сек в самый раз (для эстетов, при переходе в окно оповещения можно сделать чаще обновление, например 3 сек - это вполне разумно)
|
|||
32
alkorolev
05.01.21
✎
11:19
|
(2) а за что надо платить 50 тыс. рублей? сервис платный стал что ль?
|
|||
33
rphosts
05.01.21
✎
11:22
|
(32) для сервиса нужна лицензия корп
|
|||
34
alkorolev
05.01.21
✎
11:25
|
(33) тогда можно свой сервер взаимодействия поднять. В любом случае это лучше, чем в режиме Осла из Шрэка дергать ежесекундно (как в (31) ) сервер с вопросом "Готово?"
|
|||
35
rphosts
05.01.21
✎
11:27
|
(34) поднимай Алексей, разве кто-то против... Вот только топикстартеру наверное рановато
|
|||
36
ptiz
05.01.21
✎
11:28
|
(9) А время реакции юзера какое? Вот прям всё бросит и в течение 3 секунд побежит реагировать! А если он чай пьёт? Ни к чему 3 сек.
|
|||
37
rphosts
05.01.21
✎
11:32
|
(34) кста, если что дёргаю сиквел... Ему не сложно ибо это его планида
|
|||
38
alkorolev
05.01.21
✎
11:41
|
(37) ну дергаете то вы еще и регистр, иначе как вам инкрементные записи в сиквеле получить. Плюс время на соединение с СУБД. И всё это в интервале 1 сек...
|
|||
39
rphosts
05.01.21
✎
11:48
|
(38) проверено: не напрягает, успевает.
Да и сколько там записей то... За день пару сотен новых лишь(примерно) |
|||
40
Itmaint
05.01.21
✎
12:45
|
(29) РС прекрасно работает, когда при отправке оповещения с сервере известны ВСЕ конечные получатели. У меня увы, сложилась ситуация, что известен только объект, по которому на сервере произошло событие, а получатели - неизвестны. Соотвественно нет понимания, когда мне из РС убирать запись о произошедшем событии. Я извернулся, установив время жизни события в 30 секунд, но результатом получил проблему, что какой-то получатель за 30 секунд не прочитал запись, и как следствие не получил уведомление о событии.
Вот по этой причине сейчас перенелываю на работу с сервером взаимодействия. |
|||
41
fisher
05.01.21
✎
12:46
|
(40) Странная причина. Почему не чистить, скажем, еженедельным регламентом? В чем срочность сразу "хвосты заносить"?
|
|||
42
fisher
05.01.21
✎
12:51
|
(40) "Получатели неизвестны" - это как?
А как определяется, получит пользователь сообщение или нет? |
|||
43
Itmaint
05.01.21
✎
12:59
|
(41) (42) Если отбросить просто кривую реализацию архитектуры разработчиком (отраслевка 1с), то примерно ситуация такая: есть некий документ, есть некоторые рабочие места, которые через арм вносят изменения в этот документ. При этом арм может быть открыт на произвольном количестве мест. При изменении данных в арм, эти изменения вносятся в документ. Задача - опевестить все армы об изменениях и заставить обновиться в части внесенных изменений.
|
|||
44
Itmaint
05.01.21
✎
13:07
|
(42) мне фактически нужен некий аналог в 1с межсеансовой (между клиентами и с сервера на клиент) широковещалки типа UDP, а не TCP
|
|||
45
mistеr
05.01.21
✎
13:11
|
(0) (40) Для оповещений есть много отличного специализированного софта, не обязательно заставлять это делать 1С.
Очереди сообщений всякие, даже простой веб-сервер с пушем справится. |
|||
46
mistеr
05.01.21
✎
13:12
|
(43) Если много пользователей одновременно редактируют один документ, — это действительно кривая архитектура.
|
|||
47
Paint_NET
05.01.21
✎
13:15
|
(45) Я ещё могу представить, для чего это может быть нужно, но почему это именно так реализовано? О_о
|
|||
48
ДНН
05.01.21
✎
13:20
|
(44) http://1clancer.ru/catalog/4336
Вот неплохая широковещался как на TCP, так и на UDP |
|||
49
Прохожий
05.01.21
✎
13:39
|
(9) Разве сервер 1С не кэширует результаты одинаковых запросов? Выполняется только первый если таблица не менялась.
(41) Зачем убирать? Записывай время возникновения события в миллисекундах типа guid, а на клиенте параметр заведи - последнее считанное событие. И в запросе бери то что ещё не читал. |
|||
50
Itmaint
05.01.21
✎
13:46
|
(48) пасип
(49) да вариантов куча. просто тут уже пошли путем к правильной архитектуре |
|||
51
acht
05.01.21
✎
13:46
|
(49) > кэширует результаты
> в миллисекундах типа guid А скажи еще что-нибудь по программистки? |
|||
52
vi0
05.01.21
✎
13:59
|
можно еще посмотреть в сторону как в типовых напоминания по задачам выполняются в бизнес процессах
|
|||
53
fisher
05.01.21
✎
14:04
|
(50) Я не уверен, что вы пошли к правильной архитектуре. Мне не нравится система взаимодействий. Как продукт (концепция-то верная).
Использовать внешний сервис для внутренних уведомлений являющихся частью бизнес-логики - это быть ССЗБ. Ставить свой - дорого. Да и сопровождать этот драндулет с кучей всего на борту чего не надо для этой задачи не хочется. Я бы делал как выше предложили - на РС с таймстемпами. Если надо что-то типа уведомления о входящем звонке (которое должно быть мгновенно) - ВК с TCP-сервером. Если корпоративные чаты и т.п. - так и быть, система взаимодействий. Но использовать систему взаимодействий в качестве чего-то, что сломавшись положит оперативную работу - я бы не рискнул. На инфостарте, например, видел ветку когда у чела СВ тормозить начала как не в себя а в чем дело - понять не могут. |
|||
54
fisher
05.01.21
✎
14:06
|
Все ждали от 1С простого сервиса в составе кластера для простых серверных пушей, а они вместо этого выкатили китайскую чуду-юду - фонарик с радио на борту.
|
|||
55
ptiz
05.01.21
✎
14:31
|
(53) +100
Ради простейшей вещи: уведомлений клиента с сервера, надо городить серверы, сервисы и прочие огороды. |
|||
56
xraf
05.01.21
✎
17:34
|
(0) А задачу нельзя генерировать?
|
|||
57
ДедМорроз
05.01.21
✎
21:29
|
Система взаимодействия - это пятое колесо в телеге,особенно,если внешняя.
Если внутренняя,то ее нужно покупать,и платить дофига бабла для обмена только в 1с,как бы,глупо. А внешняя,это соединение в интернет с прокси и т.п.,что отрицательно сказывается на быстроте ее работы,ну и дыра в безопасности,само собой. Поэтому,свой сервер с уведомлениями через push,и радоваться. А для 1с можно и нажималку кнопки сделать через mshta и autoit даже не вникая в программирование. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |