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