Имя: Пароль:
1C
1С v8
Как можно оповещать клиента о событии на сервере?
,
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 даже не вникая в программирование.