Общение клиентов 1С по сети #773684

Здравствуйте, друзья! Возникла необходимость обрабатывать команду/событие на клиентах 1С. Само событие возникает на одном из клиентов 1С, на каком именно сказать невозможно. Задача заключается в том, чтобы донести информацию что событие произошло до остальных клиентов 1С. Пробовали через константу и могу с уверенностью сказать так НЕ делайте. Производительность чтения из БД упала в разы. Все клиенты переодически обращаются к БД, запрашивают состояние константы, тормозить стали даже простые журналы документов, например журнал "Заказы поставщикам". Более адекватным видится рассылка сообщений по TCP/IP протоколу. Кто знает существует ли уже готовая внешняя компонента, или писать самим? Может есть альтернативные варианты решений?

msg А сейчас ещё придёт евангелист и будет впаривать дотнет

но там же нет эмодзи!

Ну я же говорил...

AddIn.SimpleLan

что за событие? если оно возникает в 1с, то почему самой 1с не отправить на сервер и там уже обработать и оповестить клиентов

>Пробовали через константу и могу с уверенностью сказать так НЕ делайте. Попробуй через регистр.

Как с сервера 1С оповестить клиентов не трогая БД?

Можно намутить на фоновых заданиях и получении сообщений пользователю. Но проще все же вынуть руки из известного места и сделать в БД не блокируя всю таблицу констант, как у вас видимо происходит. Например

можно на регламентных. В рарусовской рознице например оповещения сделаны, правда не смотрел что они используют. В УНФ так вообще новости грузятся в справочник, а потом оттуда показываются периодически пользователям

а че константу, если мона сделать регистр сведений с измерением пользователь. запись гемморойнее, чтение норм)

если цель не озвучил, то тема явно велосипед.

РегистрСведений +  ОбработчикОжидания

Как в новом интерфейсе сослаться на сообщения? Нормально ответить не получается.

Клацнуть мышкой на номер сообщения или просто написать его в скобочках

в каком новом? Где?

ну да... Интересно, будем изучать. Может и велосипед, кто его знает. Затем и интересуюсь. Спасибо! Попробуем реализовать через регистр сведений. Может и руки немного выпрямятся.

Для этого используют задачи и обработки оповещения

Пользователи 1с все в одной сети?

да в локалке.

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

А ты кликай не по нику, а по дате ниже. Всегда так было, вроде А серый настраивается в личных настройках

у меня дата не кликабельная, просто текст.

+ как мог забыть ПАЛКА пропала! Теперь мы общаемся в обществе без цветовой дифференциации штанов.

Все нормально со штанами, это ты просто на свои ещё не заработал

у нас работает по TCP/IP. Используется интеграция 1С и .НЕТ

Ну и по Tcp/Ip

Я атеист.

Просто получение значения константы используй через повторное использование не знаю какая нужна периодичность, но кэш в любом случае висит не более 20 минут.

Термин "евангелист" никакого отношения к христианству не имеет

Давно пора 1с интегрировать отправку сообщений в платформу. Чтобы можно было из любого клиента отправить сообщение одному или всем пользователям, подключенным к текущей ИБ или ко всем ИБ сервера (в зависимости от прав доступа, разумеется) или всем в локальной сети, у кого запущен 1с.

Даже работникам другой организации, ведущейся в той же ИБ?

А при чем тут организация? Сообщения как правило технического плана "в 11:00 всем выйти из базы", и для ответа пользователя "погодиииите, у меня отчет формируется".

Тогда чем существующее в типовых не устраивает? Именно для этого сделано. Тысячи выгонялок написаны...

А что в типовой БП3.0 есть такого плана?

Евангели?сты (греч. ???????????? — возвещающие хорошую весть) Спасибо! Не думал, что ты так относишься к моим сообщениям

В моём смысле - называние человека евангелистом (в констексте этой ветки) - это не самая лестная характеристика. Так что не радуйся

В любой типовой на БСП: Администрирование -> Поддержка и обслуживание -> Блокировка работы пользователей -> Справка.

Евангелисты У этого термина существуют и другие значения... И по ссылкам: Само слово "евангелист" заимствовано из религиозной лексики, потому что используются сходные инструменты представления и распространения информации, основанные на идеологии и формировании сообщества сторонников.

Там же есть: Не давайте святыни псам и не бросайте жемчуга вашего перед свиньями, чтобы они не попрали его ногами своими и, обратившись, не растерзали вас. Св. Евангелие от Матфея 7:6

Иную притчу сказал Он им: Царство Небесное подобно закваске, которую женщина, взяв, положила в три меры муки, доколе не вскисло всё.

Это не то. Не обмен сообщениями, а выгонялка с рассылкой уведомления.

Ты в желал именно этого сценария. Это сценарий реализован. Желай что-нибудь другого?

Это я вообще не понял к чему. Но главное другое. У меня-то прекрасно работает обмен сообщениями между пользователями благодаря связке с .НЕТом без постоянного дергания регистра по расписанию, как это реализовано в типовых.

Как в этом сценарии сотрудник может ответить админу?

Это вам не надо, т.к. не реализовано 1С, а 1С лучше вас знает, что вам надо. Вот когда реализует, вот тогда вам и надо станет, а пока не надо. Выкиньте это из головы и займитесь себестоимостью и что-то там в ЗУП, отпуски чтоли съезжают

А если тебя завтра в Сосновке шампурами заколют, кто нетленку поддерживать станет?

Как и твою. Недавно работал молодой специалист, прекрасно разобрался с этим .НЕТом и что-то даже дорабатывал. Правда у него высшее ИТ, и знания не ограничены были одним православным 1С

Зелеными свистками в ватсаппе. Ты серьёзно думаешь, что админ должен сидеть и неотрывно пялится в монитор при обновлении в три часа ночи, ожидая что ему что-то ответят?

Оу, у нас есть работодатель для !

Эта специальность требует как навыков продаж и владения технологиями продвижения товаров или услуг, так и умения убеждать потенциального покупателя или пользователя, изменяя его взгляды и убеждая переходить от старых стандартов к новым. Это не про меня. Денис я тебе всегда рад. Так, что не забывай про меня.

95% админов не работают в 3 часа ночи

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

Привнесение же технологии NET в 1С достаточно спорное решение, так как технология NET самодостаточна и позволяет работать с базами данных и формами без необходимости приобретения 1С - задачу нужно рассматривать в обратном направлении - взаимодействие с 1С из сторонней программы, написанной на том же C# - это более перспективное решение, так как, во-первых, для заказчика появляется отдельная сущность программист C#, который прекрасно может разобраться в чужом коде и доработать уже написанное приложение, а программист 1С может дописывать только интеграционные HTTP-сервисы, в которых он тоже "собаку съел". Тогда, во-первых, не возникает необходимости поиска специалиста, хорошо понимающего две области, во-вторых, возможна формализация обмена данными, и как результат, более стабильная работа системы, так как отладка может выполняться отдельно для каждой стороны.

Довольно спорное решение т.к. непонятно на каком этапе в нем применить мейнфреймы, программируемые микроконтроллеры, промышленных роботов, in-memory базы данных, свистелки, перделки, синие светодиоды, и чайник со свистком.

RabbitMQ. Есть готовые компоненты для 1с

Вот именно.

Зачем изобретать велосипед? Есть проверенные решения:

Необходимость обновится может возникнуть внезапно и срочно, настолько срочно, чтобы прервать работу пользователей, но возможно есть пользователь, работу которого прерывать не стоит. Для этого и нужен обмен сообщениями, встроенный в платформу.

Есть ненулевая вероятность посещения земли инопланетянами в этом году. Надо срочно построить для них посадочную площадку.

В отличие от, указанная мной задача ставится жизнью чуть чаще чем раз в полгода

Сочувствую. И в чем же причина необходимости вот таких обновлений на горячую?

Я собираюсь подвести тебя к мысли, что нельзя решать административные проблемы программными методами. Тем более перекладывая реализацию на фирму 1с, эдакий "двойной отмаз" получается.

Собственно "профессиональный чат" для бухгалтеров одной компании полезен и сам по себе..

Ну, если от них есть постановка задания в таком ключе, тогда однозначно, это надо реализовывать.

Реализуем, сторонними программами. А так был бы определенный плюсик для 1с.

netwriter ?

Но тогда вы не сможете получать за это деньги. Ну, если конечно вы там не обленившиеся в конец фикси.

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

хотя, я, кажется, задачу не понял

Это перефразирование классической задачи сообщения от сервера всем/нужному клиенту. И чтобы клиенты не дергали постоянно сервер - "мне что есть?"

Кстати, да. Типичная массовая хотелка, которая по какой-то причине не реализуется 1с. Чтобы без повторных запросов узнать, что завершилось фоновое задание. Чтобы вывести на клиенте прогресс-бар без костылей и извращений. Чтобы делать много очень полезных и приятных вещей..

Потому что у 1С уже все есть для этого готовое и делайте в конкретном случае уже как хочется конкретно. Работа с ТО и банальным сканером ШК всем понятна к примеру? Готовых ВК дофига и нет проблем наваять очередное. И даже без ВК можно средствами 1С просто не нужно по таймеру дергать сервер насчет сообщений, пресловутую константу из . Нужно дергать после окончания действия пользователя в интерфейсе причем только тогда если таймер с предыдущего дергания уже прошел. Нагрузка на сервер и БД будет нормальной тогда, ну и желательно не константу а регистр.

+ Кто не понял про сканер то любым внешним софтом сэмулировать пикание ШК проблем нет, а далее уже вид ШК и инфа в нем.

не. Тут смесь двух хотелок - получать на клиенте сообщение от сервера и получать на клиенте сообщение от других клиентов. Первое, например на файловой базе, реализуется никак :) Второе требует административных мер по обеспечению работы одновременно минимум двух пользователь. Контроль за исполнением возложить... вот это все.

>реализуется никак :) Реализовать можно все что угодно! Нуна только выбрать подходящую ЖПО через которую будет сделано ))

А дай примеры этих интересных вещей. Кого не спросишь - все конструируют свои чаты. Вот еще умное слово "прогресс бар" всплыло. Что еще?

Причем желательно чужими руками. Оптимально - за счет платформы. "Это все они, у них все кривое" :)

тогда решение такое же классическое - long poling

там еще одна l

Это классическое решение жрет ресурсы сервера по самое не хочу.

Чем больше общих задач реализовано в платформе - тем проще будут прикладные решения и тем меньше в них будет ошибок.

Ты примеры интересных вещей из дай, философ

Через константу? Ужаснах, как такой креатив людям в голову приходит. Типа, а давайте в городе запустим трамвайную сеть и будем перевозить всех на одном трамвае...

Вариант с константой больше похож на "А вместо трамвая у нас будет рикша!"

таз с дырками для ног, а не рикша