Создано по мотивам этой ветки.
В ней AlexO утверждает, что знает способ передачи на клиента уведомления о серверном событии каким-то способом, кроме как периодическим опросом с клиента. Я пообещал ему награду, в случае если он им поделится. Также и любому другому, кто первый предоставит рабочий ответ.
Речь, естественно, не о системе взаимодействий, не о ВК, не о недокументированных методах, без внешних зависимостей, без привязок к конкретной платформе. В общем - нативный способ отобразить уведомление о серверном событии в клиентском сеансе 1С.
(1) Для начала надо понять - вы хотите оповестить какого клиента ? Сервер - один , а клиентов может быть много.
Вы хотите запихнуть событие сервера во все клиенты ?
А чем занимается конкретный клиент Дяди Васи в тот момент, когда вы хотите ему что-то передать ? Напоминаю - каждый клиент по сути - однозадачный однопоточный процесс. То есть , если клиент выводит на форму полученные данные ему плевать на ваши серверные события.
Второе. А где собственно происходят эти события ? В каком-то Объекте базы ? События не происходят на сервере , они происходят в серверном модуле какого-то Объекта.
Если Объект сервера и открытый объектКлиента - это один и тот же объект , то Ставите процедуру опроса ЗАПИСАННЫХ событием сервера данных и получаете реакцию. Записываться могут только в Реквизит объекта, а не в реквизит формы. Потому как вызова Клиента в Серверной процедуре не существует - какого клиента ? Дяди Васи или Дяди Пети ? Или Татьяны ?
22.
Yulka_Pentagramma
27.02.20 11:08 Сейчас в теме
(19) продолжение беседы, конкретно с Вами, считаю нецелесообразным. Судя по Вашим ответам в начальной теме в 1С вы разбираетесь ещё хуже меня, а понтов, как у программиста....
чего стоит
Приколько. Как 1С инициирует и отправляет POST к сайту я знаю. А вот как обратно , учитывая , что эти понятия ( запросы POSTи GET) созданы для запроса к Интернет Ресурсам, к которым 1С не относится , если не считать Публикации базы . но Там только клиент .
В той теме вы так и не ответили... Серьезно? Только клиент при публикации базы на сервере?
(22) Вполне возможно какие-то тонкости работы 1С в режиме НТТР я ещё не усвоил , но это не повод матом гнуть. Я не встречал ни одного программиста , который не ошибается. Откройте ИТС или любое обновление и посчитайте количество ошибок , которое исправляет сама 1С.
Дело не в этом , а в методах общения. Обсуждения и даже споры всегда на всех форумах у программистов в почете. Не нравится моё мнение с технической точки зрения - можно просто не отвечать.
42.
Yulka_Pentagramma
27.02.20 22:45 Сейчас в теме
(39) я вам ответила очень корректно, что у меня самописная конфигурация, описала механизм создания документов, пояснила, что дяди Васи нет...
Вы не слышите входящих данных и продолжаете привлекать новых действующих лиц... дядю Петю и Татьяну...
переиначивать мои слова... что у меня какая-то, неведомая мне, обработка сайт опрашивает...
я сама всё это пишу, и сайт, и приложение, и HTTP-сервисы - приемники в 1С, и уж наверное я знаю, как этот функционал реализован...
Ваши комментарии читают другие участники обсуждения, и могут вводить их в заблуждение... ну и последней каплей стало переписывание сообщений на которые я вам уже ответила... задний ум это хорошо, необычно, но опять же ставит в неловкое положение меня, как инициатора темы, потому что мои ответы вам переходят в категорию бреда...
Русский язык могуч и богат, но лучшего эпитета, который мог бы остановить этот (8) поток рассуждений, я не нашла. Уж извиняйте.
(1) про бизнес-процессы и механизмы напоминания тоже речи не идёт ? Создался на сервере документ , автоматически запустили БП с указанием нужного пользователя , у нужного пользователя появилась задача обработать документ
А других методов передачи сервер-клиент нет. И речь не про встроенный язык 1С – тут просто другого принципа не может быть.
Да, клиент 1С прослушивает сервер нативно, благодаря чему мы можем использовать метод Сообщить() на сервере, но инструментов для использования этого опроса во встроенном языке нам не дали.
(37) Вполне возможно есть. Как говорят - недокументированные. Ведь по сути клиент и сервер , это два процесса, связанных ID. Есть внутренний протокол и т.п. Данные гоняются туда сюда и ещё не факт . где там Master а где Slave )) в каждый момент времени.
Для меня очевиден факт, что 1С выросла со всоих штанов. Была задумана и реализована , как учетная программа, а теперь все больше преобретает характер управления всеми аспектами любого бизнеса.
Вот тебе и не язык программирования , над которым потешались все ПРОГРАММИСТЫ с большой дороги )))
(1) без СВ и дерганья только оповестить о изменениях, но тут стоит отметить что оповещения получат все клиенты, а не те, которые нам нужны и это после завершения серверного кода.
Так что тему можно закрывать и выдать вознаграждение.
Ну можете еще написать в ТП, но ответ будет аналогичный.
Именно для таких целей сделали СВ. Кстати для тех у кого его нет и больше 10 пользователей могут за полтос купить!
Кстати в РБ СВ бесплатный, точнее в проф входит!
(1) Так близко - и так далеко, "нативного" способа нет и не было раньше, для некоторых задач это конечно очень сильно мешало и мешает. Раньше в самом направлении платформы это было за ненадобностью, со временем эти устои укрепились. Можно отойти немного в сторону и посмотреть, как этот недостаток решается. Решается он опросами сервера, различными компонентами, придуманными длительными операциями и системами взаимодействия. Если подумать то становиться даже страшно, сколько сил задействовано для решения данного пробела, и невозможности решить это на платформенном уровне. Еще умиляет обилие троллей, которые не понимают или не хотят читать то что написано в требуемом и предлагают какую-то ерунду.
Для меня загадка почему это не реализовано на уровне платформы нативным способом, простым и применимым в простых ситуациях. Да можно извернуться и как-то завернуть этот костыль, но есть задачи где это нужно, а этот костыль городить будет излишним. Т.е. с одной стороны все видят что это нужно, сделали убожество по модулям и длительным операциям, сейчас придумали урода систему взаимодействий. Как все плохо, эх, беда.....
судя по статьям от 1С - такой возможности нет.
Все остальное это танцы с бубнами вокруг обработчика ожидания или автообновления со стороны клиента.
Ну а почему бы и нет? вся идеология работы 1С построена на этом, идет постоянное сканирование/получение данных с сервера.
Как вариант сервер, что-то пишет в Регистр сведений, вы открываете форму с Динамическим списком к этому регистру, при открытии устанавливаете нужные параметры/отборы, у ДС есть ПериодАвтообновления - в общем и все
(3) Так и есть.
(5) Чаще всего используют специальные ВК для этого.
(6) Вообще, предполагалось что периодический опрос вы сделаете через ПодключитьОбработчикОжидания()
(7) "Поднять на сервере HTTP-сервис. С клиента подключиться к этому сервису и удерживать соединение"
Каким образом вы собираетесь "удерживать соединение"?. Разве 1С уже поддерживает websocket? Это раз. "не возвращаться из обработки сессии" - это блокирующий вызов, что ли? А клиенту как работать в это время? Короче, нифига непонятно. Есть рабочая схема или более понятное объяснение? Может, кусок кода из работающего варианта?
(8) Первое. Механика не так важна. broadcast бы тоже подошел. По такому же принципу работают локальные оповещения. Их ловят все окна, а обрабатывают те, которым это интересно. Второе: считаем, что событие произошло в обработчике регламентного задания.
(9) "...и механизмы напоминания тоже речи не идёт?" Какие еще "механизмы напоминания"? В платформе я про такие не знаю. В БСП - загляните под капот и перечитайте сабж.
(11) Хм... Насколько я понял по вашим ответам, вы сделали через работу с динамическим списком и его период обновления. Или вы просто так хитро выкрутились с динамическим списком, чтобы не заводить очередь уведомлений? Про минусы такого подхода я уже писал.
В любом случае к вашему сбою это отношения не имеет. Синий экран смерти - это аппаратные проблемы или проблемы оси.
(16) Я знаю, как работает эта подсистема. А вот вы, судя по всему - нет. Либо невнимательно читали сабж. Я только что там жирненьким подчеркнул для невнимательных.
(23) Суть - подписаться на клиенте на серверное событие, чтобы своевременно его получать. Сейчас в платформе это не решено никак. Вернее, решается в рамках использования системы взаимодействий. Но система взаимодействий - это гораздо более общее решение. Оно небесплатно и требует либо действующей подписки на ИТС и использования внешних сервисов 1С, либо приобретения КОРП-лицензий (к тому же требует установки и администрирования целой связки дополнительного ПО). Нужную функциональность несложно было реализовать in-process (что и доказывает существование множества ВК), но у 1С немного другие приоритеты.
подписаться на клиенте на серверное событие, чтобы своевременно его получать
система подписок появилась в 8.1 1С.
Оно небесплатно и требует либо действующей подписки на ИТС и использования внешних сервисов 1С, либо приобретения КОРП-лицензий
ничего оно не требует, окромя прямых рук и светлой головы.
Второго катастрофически недостает в 1С. Из-за чего все проблемы.
Нужную функциональность несложно было реализовать in-process (что и доказывает существование множества ВК
да, великое множество...фейспалм.
но у 1С немного другие приоритеты.
У 1С ВК были в планах только в 7.7. И то если не мешало основному функционалу. Больше ВК в планах 1С и в "приоритетах" никогда не было, почти 20 лет уже.
Система взаимодействия ‑ это механизм, позволяющий взаимодействовать между собой клиентским приложениям, серверу и пользователям одной или нескольких информационных баз.
Вот моя цитата:
Но система взаимодействий - это гораздо более общее решение.
В рамках которого решается и проблема серверных пушей, поскольку она взаимодействует с клиентами через WebSocket и имеет API, позволяющий взаимодействовать с клиентами программно в режиме реального времени.
Это раз. "не возвращаться из обработки сессии" - это блокирующий вызов, что ли? А клиенту как работать в это время?
Что-то в памяти моей всплывает на это счет. На каком-то IE был доклад про YellowRabbitMQ. И если я правильно запомнил, как раз про этот момент и рассказывали. Соединение удерживается регламентным заданием, т.е. в фоне, в течение получаса, потом закрывается, завершается регламентное задание, а уже через пару секунд вновь стартует (согласно расписанию) на следующие полчаса.
здорово, что есть программисты, которым "подвесить на полчаса регламентным заданием" всю систему - ничего не стоит. "А что, почему бы и нет, все так делают..."
Понятно теперь, кто типовые пишет...
если у вас регламент именно в выполнении каких-то операций с оперативными данными - то "висяк" вам гарантирован: сразу же и бесповоротно - блокировка таблиц, коея проблема в 1С не решалось изначально - поэтому 1С ни разу не СУБД.
А потом уже и объемы дают о себе знать - что, какое количество запрошено в регламент, насколько там тяжелый алгоритм обработки.
Файловая тут вообще ни при чем, в далеком 2004 1С сразу заявила - "файловая 1С8 это только как демонстрация возможностей и обучения, и не может использоваться для проектных решений".
Что надо понимать так: "мы не смогли разработать ни систему хранения данных, ни их обработку, ни анализ, ни администрирование массивов данных. Просим понять нас и простить, и сделать вид, что 1С классная, а всякие SQL-ORACLE-DB2 вообще тут ни при чем, это так, для красоты и понтов".
именно в выполнении каких-то операций с оперативными данными
Так как раз мы обсуждаем не обработку данных в информационной базе, а удержание соединения. Висит себе и висит регл. задание параллельно с другими, никому не мешает. Мешать будет в файловой, потому как файловая база не поддерживает параллельное выполнение регл. заданий, если конечно мне не изменяет память.
Поднять на сервере HTTP-сервис. С клиента подключиться к этому сервису и удерживать соединение - не возвращаться из обработки сессии, пока не будут получены данные для отправки - найден файл с данными, переподключаться при разрыве по таймауту. При возникновении события сохранить файл для пользователя. Этот файл прочитать в установленной сессии, которая ожидает данные. Удалить файл и вернуть его данные клиенту, закрыв соединение.
Очень ненадежная схема, но средствами платформы лучше ничего не придумать.
Я бы делал отдельный сервер оповещений не на 1С + регулярный опрос с помощью HTTPСоединение.
Оповещение с сервера на клиента конечно очень классно, но без обработчика ожидания / внешнего события / системы взаимодействия я думаю это невозможно, если невозможно использовать систему взаимодействия пишите dll которая будет генерировать внешнее событие с сервера, но, кажется, это попахивает бредом
сли невозможно использовать систему взаимодействия пишите dll которая будет генерировать внешнее событие с сервера, но, кажется, это попахивает бредом
Почему бредом? Кому надо - все так и делают. Пишут ВК, с помощью которой устанавливается соединение между сервером и клиентом и по которому сервер может пушить сообщения на клиента, которые тот ловит в обработке внешнего события.
Пишут ВК, с помощью которой устанавливается соединение между сервером и клиентом
к 1С это какое отношение имеет? Потому и бред пишите, что вопрос про 1С, а не "вообще".
И да, удачи вам и с ВК для соединения клиента и сервера 1С, и "вообще".
т.е. про вариант с подпиской ты забыл, но тему с такими же незнайками создать не преминул...
Выкладываете демо-конфу с "вариантом с подпиской", удовлетворяющую условиям из сабжа и забираете выигрыш. Потому что я ни про какие "варианты с подпиской" не знаю. Что такое механизм подписок я конечно же знаю. Но сабжевую проблему подписки не решают никак от слова "совсем".
Но у вас есть какая-то уникальная информация, которую я уже второй день пытаюсь из вас извлечь.
(34) там не "механизм подписок" или чего там вы изобретаете, а подписка на конкретное событие конкретной задачи - подписка на создание документа, и от этого - рассылка уведомления пользователю.
И снова <сбился со счета в который раз> прошу вас продемонстрировать механизм отображения на клиенте уведомления о серверном событии не через периодический опрос с клиента.
Подписку проехали. Сработала ваша подписка. Событие на сервере поймали. Теперь нам нужно отобразить уведомление об этом в клиентском сеансе. Как? Именно про это весь сыр-бор. А не про перехват события на сервере.
ЗЫ. Я до сих пор не могу понять, это вы так троллите или реально не въезжаете в суть проблемы. И какой из этих двух вариантов печальнее.
(29) Если вы выкатите рабочее решение, то думаю что проставлюсь не только я, но и разработчики БСП и еще куча незнаек. Это ж сколько проблем можно будет одним махом решить! Эх...
Очень интересны варианты решений как раз в зависимости от требуемого результата и от поставленных задач.
Вот например, известно, что форма сначала создается на сервере, потом открывается. Получается, на сервере можно написать что угодно и потом передать и обработать на клиенте. Или поставить условие, передавать или нет.
(31) суть в том что нужно получить ответ от сервера, пока он не завершил процесс, а это умеет только СВ!
Когда процесс завершен, то не имеет значения как получить результат!
получается, на сервере можно написать что угодно и потом передать и обработать на клиенте.
Не "что угодно", а что получится. Потом еще попрыгать чтобы передать на форму УФ. И обработать на форме - это вообще из разряда "прыгнуть выше головы": что-то как-то можно в небольших дозах, если масса времени ковыряться, но лучше на сервере и сразу.
А пока что я объявляю вас троллем 90-го уровня :)
Если докажете свою правоту, то кроме выплаты вознаграждения готов на каждом углу посыпать свою голову пеплом и прославлять ваше величие.
(35)а я, со своей стороны, пока вижу только недотеп, которые кружат в 3х соснах, вместо того, чтобы помочь 1С решить их задачу. И 1С не может, и хороводчики запутались.
(35) Тут многи палятся на том, что не понимают простой вещи, что сервер один, а клиентов - много. Даже если и был бы механизм подписок, непонятно, какому клиенту слать данные. Широковещательный посыл - это каменный век, так можно и через MSMQ сделать с помощью консольных утилит винды. Индивидуальной адресной подписки в 1С нет и не может быть реализовано в текущей архитектуре (клиент-сервер). Для решения этих задач даже в обычном вебе еще не до конца выработаны стандарты, вебсокеты все еще сыроваты и имеют проблемы. Более-менее это все решено с помощью брокеров сообщений, под которые и пытается мимикрировать подсистема взаимодействия в 1С .
(58) Зачем Вам пруф? Вы же на 1с программируете. А я не только на 1с. В других языках уже давно обсуждаются проблемы вебсокетов. Программистам 1с эти знания недоступны в силу тотальной изоляции от конкретных технологий.
(91) "Недостатки технологии" <> "сырость технологии". Откуда вам знать, какая область моих интересов? И почему вы пытаетесь перевести разговор в эту плоскость вместо простого ответа на простой вопрос? Нет, я конечно догадываюсь, почему. Но не люблю заранее разочаровываться в собеседниках.
А вот еще цитата из документации системы взаимодействий:
Реакция на сообщения реализуется путем подписки клиентского приложения на появление новых сообщений в каком-либо обсуждении. В данный класс задач могут попадать следующие задачи: оповещения клиентского приложения о выполнении некоторых служебных действий (например, перезапуск клиентского приложения), отображение состояния выполнения длительных задач, выполняемых на сервере и т. д. Подключение обработчика новых сообщений выполняется с помощью метода НачатьПодключениеОбработчикаНовыхСообщений().
придумали себе какую-то систему.. какие системы в 1С?!
Пользуйтесь тем, что есть.
Хотите - НачатьПодключениеОбработчикаНовыхСообщений(), если будет работать. Я уже перечислял массу команд для передачи сообщения пользователю в основной ветке.
придумали себе какую-то систему.. какие системы в 1С?!
Пользуйтесь тем, что есть.
Хотите - НачатьПодключениеОбработчикаНовыхСообщений()
Это вы специально так подставляетесь, что ли? Никогда не понимал того кайфа, который видимо получают тролли. Типа провоцирование людей дает иллюзию контроля и ощущение превосходства? То есть в реальной жизни ни того ни другого не хватает?
(53)
Я уже перечислял массу команд для передачи сообщения пользователю в основной ветке.
Да. Вы много чего перечисляли. Не имеющего отношения к проблеме. Может, все-таки предоставите работающее решение и заберете выигрыш? Как мне еще вас уговаривать? Я за девушками так не ухаживал.
(63) согласно посту (0) исчерпывающий ответ таких возможностей нет!
Если углубиться в тему и снять некоторые ограничения, то будет простор для маневров.
Вопрос только какие ограничения готовы снять?
(66) Перечитал (62)
Ответ на (64) - вариант снятия ограничений меня не интересует.
Теперь ответьте пожалуйста по (51):
без СВ и дерганья только оповестить о изменениях, но тут стоит отметить что оповещения получат все клиенты, а не те, которые нам нужны и это после завершения серверного кода.
Меня полностью устроит такой вариант. Покажите, как мне его реализовать и я выдаю вознаграждение.
(67) если не смущает, что оповещение получат все клиенты, а не нужные вам, то все просто.
Читаем справку по
ОповеститьОбИзменении
Эта штука работает для ссылочных типов. Или когда изменений много для динамических списков, чтобы они как минимум обновились после получения оповещения.
Далее есть процедуры обработки оповещения.
А вот тут вы можете уже начать игру как это оповещение отработать.
Ну думаю все понятно о чем шла речь?
Но такой алгоритм оповещения может сильно повлиять на производительность, у меня был клиент где так 200 пользователей оповещались, а в ДС был тяжелый запрос. Они просто вешали базу!
(69) да возможно была особенность. Код выполнялся на сервере, но затем он передавался на клиент администратору и тот всех оповещал.
Хотя возможно это работало на лохматой платформе 8.3.8, а вот в 8.3.16 уже не сработает.
Поэтому остается только метод дергать проверку с клиента:
1. Администратором через "ОповеститьОбИзменении" на клиенте для всех клиентов.
2. Фоновым заданием каждым клиентом персонально с прогрессом, который передал сервер.
3. "ПодключитьОбработчикОжидания" каждому клиенту персонально о завершении работы сервера.
4. Обработка внешнего события, по принципу, как работает сканер штрихкода.
(70) про эту часть точно не путаю. Переписывал потом клиент тяжелый запрос.
Да, там администратор менял доки и после этого шло оповещение. Значит и там скорее всего это было на клиенте, но подтвердить сейчас не могу.
Это не может служить доказательством. Если у вас действительно был тяжелый запрос в ДС, то достаточно было чтобы много клиентов часто обновляли ДС, чтобы "повесить базу".
Я пока не могу придумать как использовать ДС для получения уведомлений (как минимум на клиенте должен быть открыт ДС для этого). Но если вы сможете доказать что через него можно получать уведомления от других клиентов в принципе - то я выдам вознаграждение.
Но периодическое автоматическое обновление ДС на клиенте само по себе не может являться таким механизмом - это тот же самый периодический опрос с клиента. Те же яйца - вид сбоку.
Примечание:
Уведомление не влияет на динамические списки, у которых не задана основная таблица.
Динамические списки в тонком и веб-клиенте не обновляются при изменении данных в базе данных автоматически. Обновление динамического списка происходит при явном вызове метода, а также при выполнении стандартных команд записи данных форм.
Также осуществляется очистка закэшированных данных на клиенте. В частности, очищается кэш представлений ссылок, кэш данных через точку, кэш данных быстрого выбора, кэш ограничений по типу, кэш форм выбора. Удаляется только та информация, которая стала недействительной.
И да, ДС должен быть открыт, если он закрыт, то некого оповестить!
(75) Не вижу, какие магические слова из СП должны меня убедить в вашей правоте :) Я прекрасно знаю что это за метод, для чего он и как работает. И не раз его использовал. И я утверждаю, что он никакие оповещения на других клиентов не рассылает. Если докажете обратное - я извинюсь и выдам вознаграждение.
Доказать очень просто: говорите мне - вот демо-база. Открываете два сеанса с динамическими списками с отключенными автообновлениями. В одном сеансе нажимаем кнопку - во втором сеансе ловим это событие. Вообще мне надо с сервера, но как мы выяснили с сервера это не работает. Так что сойдет хотя бы с одного клиента на другого.
(76) да, проверил. По кнопке администратор только у себя обновляет ДС.
Выходит нужен триггер, чтобы клиент у себя его вызвал.
Не могу проверить как это было у клиента реализовано, но точно помню что все вешалось из-за сложного запроса в ДС и частого вызова оповестить, что вызывало его обновление. Там речь шла о таблице с миллионами записей.
Ваш вариант это как и было сказано делать запись в регистр, на сервере или на клиенте это уже не важно.
И далее по кнопке или через обработчик ожидания получить нужный для вас результат пользователю.
А алгоритм получения уже сами пропишите.
Это все реализовано скорее всего в БСП и конфигурации CRM.
(77) Да я в курсе как это делается и как реализовано в БСП. И предложил именно такой вариант, когда человек спрашивал. Но AlexO вывел меня из себя утверждениями что это бред, отстой и непрофессионально. Намекая на то, что он знает как можно это сделать правильно. И продолжал это делать даже после всех вежливых уточнений по задаче. Как вы могли заметить, и в этой ветке он вел себя также. Поэтому на ваши отсылки к перечитыванию (62) я могу только недоуменно пожимать плечами.
(78) в CRM есть похожий алгоритм. Справочник триггеры. При срабатывании нужного действия выполняется ваш алгоритм. Но он все равно строится на оповещениях, а работу выполняет сервер.
Второй вариант это бизнес-процессы, пользователь А сделал действие, которое должно завершиться действием пользователя Б.
Но БП это частный случай. Как пример БП "Поручение", его может запустить, как пользователь, так и запуск выполнен кодом.
Есть огромная разница, что конкретно писать и что конкретно подразумевать.
Поэтому самое главное это какой был контекст об этом я вам в (62) и сказал.
(79) Вопрос был про механизм оповещений клиента, а не про его применения. Применений бесконечное количество. А вот механизм оповещений (если не брать СВ) ровно один - ходить с клиента на сервер с вопросом "есть чо"? Если вы с этим не согласны, как и AlexO - то демонстрируете наглядно и забираете выигрыш. Какие тут могут возникнуть непонятки с контекстом - я в глубоком недоумении.
(59) а по поводу ответов вашего оппонента, то просто вы не умеете его ответы готовить.
Иногда дает неплохую пищу для размышления, а вы пытаетесь найти какой-то сокральный смысл в этом всем, когда его нет!
Таким способом невозможно оповещать других клиентов. Это метод для того, чтобы оповестить открытые на ЭТОМ ЖЕ клиенте динамические списки об измененных рядышком данных.
(83) Можно так, при получении уведомлении на сервере, создать задачу исполнителю. И указать время +5 сек.
Пользователю придет уведомление о новой задаче
Либо через напоминание, если есть регистр сведений "НапоминанияПользователя" можно через него оповещать.
И там и там можно указывать конкретных пользователей. Список пользователей можно получить так "ПолучитьСоединенияИнформационнойБазы()" или
"ПолучитьСеансыИнформационнойБазы()".
(84) Оба упомянутых механизма типовых конфигураций используют периодическую проверку с клиента наличия на сервере тех самых задач и тех самых напоминаний. Что немножко не подходит под выделенное жирным шрифтом условие в заголовке темы.