8.х Вызов сервером обработчика события на клиенте

Тема в разделе "Конфигурирование на платформе "1С:Предприятие 8"", создана пользователем sobenko, 1 мар 2012.

  1. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Платформа 8.2. Архитектура- клиент-сервер. Задача: нужно чтобы сервер вызвал определенную процедуру на определенном клиенте, подключенном к серверу.
    Возможно-ли это реализовать и как?
    (Это что-то сродни принципу работы ICQ и тому подобного софта, когда не обработчик ожидания опрашивает периодически сервер, а сервер сам вызывает обработчик события на клиенте).
  2. alexburn
    Offline

    alexburn Модераторы Команда форума Модератор

    Регистрация:
    5 янв 2009
    Сообщения:
    14.735
    Симпатии:
    508
    Баллы:
    204
    С сервера невозможно вызвать клиента, можно только с клиента вызвать сервер, после выполнения "серверного" кода, управление возвращается обратно на клиента.
    Извините, такая уж архитектура, и не понятно для чего с сервера вызывать клиента. Разбиритесь с архитектурой 8.2.
    Или изложите мысль более понятней, для чего нужно и какая цель приследуется.
  3. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Задача состоит в том, чтобы реализовать механизм уведомлений пользователей о наступлении определенных событий. К примеру менеджер создает заявку на оплату счета или счет. Бухгалтер (находящийся далеко от менеджера) разносит банк. И когда бухгалтер проводит платежку на оплату счета менеджера- менеджеру приходит сообщение (выскакивает окошко) о том, что счет проплачен (как к примеру в ICQ и др. интернет-мессенджерах). Реализовать это можно 2-мя путями:
    1) через обработку ожидания, когда клиент "тыкается" на сервер через определенный интервал времени;
    2) когда клиент просто слушает сервер и когда от сервера приходит сообщение, на клиенте отрабатывает определенная процедура.
    Если с ситемой работает пару-тройка клиентов, то впринципе 1-й вариант решения не вызовет больших проблем. Проблемы начинают возникать когда число клиентов возрастает до нескольких сотен, а ингда даже и несколько десятков могут конкретно забить траффик и загрузить сервер. Режим работы, когда клиент подписывается на список событий на сервере и дальше переходит в режим "прослушки" уменьшает бесполезный траффик в разы и не грузит сервер бесполезными запросами. К примеру зачем периодически выполнять обновление формы списка, если в нем не происходило ни каких изменений? Зачем периодически опрашивать какой-нибудь регистр сведений или задачу, когда в нем ничего не менялось? Менялось или нет знает только сервер. По этому логично чтобы не клиент посылал каждые 5 секунд на сервер запрос и получал один и тот-же ответ, а сервер при подписке на событие (к примеру "при записи" для задачи) вызывал обработку этого события на "заинтересованных" клиентах. Сейчас события обрабатываются только на тех клиентах, которые непосредственно инициировали это событие, а хотелось-бы чтобы событие обрабатывалось еще и на других клиентах (только другим обработчиком).
    Такой принцип работы браузеров обеспечивает технология WebSocket, которая уже в прошлом году стандартизирована (http://www.rfc-editor.org/info/rfc6455) и поддерживается 4-мя браузерами (кроме Internet Explorer). За этой технологией- будущее.
  4. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    800 пользователей. Полет стабильный и нормальный. Все зависит от того, как выбирать нужные данные :) Траффик, кстати, минимальный.

    За тем, что бы не сервер следил за тем, какие сейчас отборы стоят у пользователей в списке, например.
    Также затем, что если пользователю нет нужды обновлять список -> нет нужды тащить данные списка на клиента (не забываем, что на клиента идет только то, что он увидит +2 строки снизу и сверху. Зачем все это серверу?)

    Серверов может быть много. В части управляемого приложения - постоянной связи с сервером нет. Ваш запрос может обработаь процесс на другом сервере в кластере.
    Зачем кластеру (на котором может работать тысячи пользователей)помнить все настройки всех пользователей? Что бы память засрать окончательно? :)


    1С является УЧЕТНОЙ, а не биллинговой системой. Ей такое не требуется. Поэтому задача о 5 сек решается иными способами (если она вообще нужна).
  5. uza
    Offline

    uza 1С, VBA (EXCEL), VB (.NET + WEB)

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    Ну про оповещение по e-mail вы вот чего то даже не сказали - а ведь просто организуется, и штатными средствами.
    Ну и собстна можно же к 1Ске прикрутить ICQшник (гуглим либы, курим маны, катаем код) - но IMHO гемор не стоит свеч.

    Но есть и другой способ.

    1) Пишем свой простенький клиент. Который обеспечивает либо:
    (а) регулярное обчитывание базы данных (сторонней, например) на наличие записей в таблице с признаком "IsNew_Blead"
    (б) просто сидит, и слушает выделенный порт (на порт он ждет пакеты данных)
    2) В 1С, в обработке при записи документа пишем код, который анализирует является ли это первая запись, и менялось ли что то существенно с момента последней записи (а то бухи могут документ просто перепроводить, и каждый раз манагеру по этому случаю стент приходить веселый месыдж) и если это новый документ, или он изменен существенно (сумма, плательщик, назначение) то:
    Для варианта А - создаем в отдельной (а можно и не в отдельной) в нашей таблице запись, с той самой пометкой IsNew_Blead
    Дла варианта Б - стартуем ВКшку (да хоть бы и тупо EXEшничек с параметрами командной строки), которая инициализирует "пинатель" на тот самый выделенный порт.

    Ну как то так.

    Но EMAIL - имхо, проще, и не требует написания дополнительных костылей.
    В обработке записи платежных документов пишем код, который при необходимости (дабы при перепроведении старого дока манагера не тревожить) помещает в сторонюю БД
  6. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    А что, в учетной системе обеспечение актуальности данных является 105-м делом?! К примеру в крупной торговой компании где в системе сидит пару сотен менеджеров не надо, чтобы они видели актуальные остатки, цены товаров? Если этого не будет, то менеджеры по телефону будут обещать товары, которые уже другой менеджер продал, называть устаревшие цены и т.д. А включив периодическое обновление формы списка прайса получаем бесполезную загрузку сервера и значительное увеличение бесполезного трафика.
  7. alexburn
    Offline

    alexburn Модераторы Команда форума Модератор

    Регистрация:
    5 янв 2009
    Сообщения:
    14.735
    Симпатии:
    508
    Баллы:
    204
    А менеджеры настолько тупые что не могут сами обновить форму???????????
  8. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    А в преимущестово этого метода? Только в переносе нагрузки с сервера 1С на почтовый сервер? Ведь все равно клиенту придется периодически опрашивать сервер.
    В чем разница между письмом и телеграммой? Телеграммы раньше разносили почтальоны и вручали лично в руки. Телеграммы-молнии вообще разносили сразу после поступления на почтовое отделение. А за письмом клиенту надо периодически заглядывать в почтовый ящик. В течение суток к примеру приходит 2 письма, а клиент заглядывает в ящик каждые 10 минут. Их всех "заглядываний" только 2 успешных, а остальные бесполезны. А вот с телеграммой все идеально. Клиент занимается своей работой, а когда почтальон приносит телеграмму, он прерывается и получает ее, не тратя время на бесполезную беготню.
    Мне не ICQшник в 1С нужен, я про принцип работы ICQ писал.
    Этот метод работы и реализован сейчас платформой обработчиком ожидания. Но он очень не оптимален.
    А вот так как раз и реализован протокол WebSockets. Этот метод максимально оптимален, но не реализуется в 1С.
    Ну вот в том-то и дело, что платформа для написания приложений, рассчитанных на очень много-пользовательскую работу, работает не особо оптимально.
    А про ВК-шку (экзэшник это тоже на то) из варианта (Б), кто может ее написать?
  9. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Конечно смогут! Более того, они догадаются, что если в настройках списка формы поставить галку "Обновлять автоматически каждые" и период 5 секунд, то можно на кнопку "Обновить" и не жать. Только на сколько тогда скакнет нагрузка на кластер (сервер) и увеличиться бестолковый трафик по сети от 200 клиентов?!
    Совсем другое дело когда на сервере отрабатывает обработчик "ПриЗаписи" и из него вызывается оповещение нужных клиентов, а клиенты уже формируют запросы и обновляют свои формы. В этом случае всплески трафика и запросов к серверу будут не когда попало, а только когда это действительно необходимо.
  10. alexburn
    Offline

    alexburn Модераторы Команда форума Модератор

    Регистрация:
    5 янв 2009
    Сообщения:
    14.735
    Симпатии:
    508
    Баллы:
    204
    А вы представляете если все 200 манагеров будут поочередно, проводить, распроводить, записывать документы??????
  11. uza
    Offline

    uza 1С, VBA (EXCEL), VB (.NET + WEB)

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    У вас сильно эти 200 манагеров своими "бугагашками" по мылу ложат сеть?
    Если сильно - то дрянь у Вас, а не сетка.
    Там трафика то - тьфу. Чего на пустом месте изобретать лесапеды?

    Вот когда возникнет "да, сетка еле ползает" и при этом вы будете уверены, что это из за этого авто-опроса раз в 5 секунд - вот тогда и станете репу чесать.

    А так то да, alexburn верно заметил, если вы боитесь что 200 менеджеров фоновым опросом тупо остатков нагрузят вам сетку и кластер, то что же будет, когда они еще и работать начнут? При проведении документов запросы то прут - не в пример сложнее.
  12. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Посмотрите типовые - там так и сделано. К слову, у нас в корпоративной базе - тоже так.
    Ничего, все живы и здоровы. Тут вопрос в том, как построить эти данные. Если фигачить от балды - я на пустой базе положу Вам сервер, не шибко напрягаясь.

    Зато обеспечивает кучу геморроя по синхронизации сервера с клиентом. На текущий момент - клиент инициатор связи, а Вы предлагаете все наоборот сделать :)
    Поясню еще одно: что должно произойти, когда у пользователя во весь экран открыт документ и пришло оповещение с сервера, что надо бы этот документ обновить?
    Уткнетесь в то, что надо будет такое событие отрабатывать, думать о том, что пользователь изменил и как все это связать в одно. Замудохаетесь, проще говоря.
    И еще: случай в вакууме рассматривать бесполезно. Нужна конкретика.

    Уточните, чем отличается запрос к базе сервером (для получения подписок) от запроса со стороны клиента? Это одно и тоже :) Что и с самого начала Вам говорили.

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

    Подумайте, что произойдет по Вашему сценарию на 1000 пользователей.
    Форма остатка у Вас будет обновляться бесконечно (количество будет менять постоянно - ибо 1000 пользвоателей!)
    Отсюда вывод - остаток НЕ имеет актуальности после его прочтения.
  13. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Вы слышали когда-нибудь что-нибудь об оптимизации работы приложений? К примеру зайдите на сайт http://www.gilev.ru и посмотрите как работает типовая до и после оптимизации.
    Я как раз и веду разговор что методика "тыкания" клиентов в сервер, по сравнению с методикой оповещения сервером нужных клиентов, является жутко не оптимальной. А если есть неоптимальность в приложении, то это обязательно "вылезет боком" при увеличении нагрузки на систему.

    Этот процесс невозможно исключить, а вот процесс бестолкового "тыкания" клиентов в сервер для выяснения обновился список или нет можно заменить на гораздо более прогрессивный метод оповещения сервером нужных клиентов.
  14. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    А помните, что платформа 8.2 еще может в режиме тонкого клиента, а еще и на медленных соединениях работать?! А теперь подумайте, если на медленном соединении исключить часть бестолкового трафика, быстрее будет клиент бегать?
  15. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    И что? Траффик может генериться и от бестолкового испоьзования программы. ВЫ так и не привели паттерн использования (про остатки уже сказал, к слову - посмотрите на крупные инет-магазины, как они устроены. Никакого оповещения с сервера нет у них)

    Не путайте методы Славы для конфигурации со своими предложениями о платформе. Как раз-таки Слава и делает процесс обмена сервер-клиент минимальным.

    Еще раз: приведите паттерн. На общий вопрос вы получили общий ответ. Когда будет видна конкретная задача - уже имеет смысл обсуждать.
    Минусы дерганья с сервера клиента в двух словах я уже описал.
  16. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Типовые так написаны потому, что:
    1) так написана платформа и за ее возможности не перепрыгнеш, не используя ВК.
    2) в типовых иногда пишут такой код, за который никогда в жизни 1С не зачел-бы экзамен.
    Никакой геморой не предполагается и не полностью все наоборот. Клиент открывает соединение, а дальше понятие "клиент" и "сервер" стирается. Инициирует передачу тот, кому это надо сделать. Прочитайте пожалуйста http://ru.wikipedia.org/wiki/WebSocket. Неужели это "чайники" придумали?
    В курсе, что если для события не назначена процедура обработки, то это событие и не обрабатывается? Это уже разработчику решать, надо или нет обновлять форму документа, если его кто-то изменил. А думать о том, что пользователь изменил вообще не надо! Попробуйте открыть один и тот-же документ на разных клиентах и изменить реквизит на одном из них. Что происходит? Правильно, запись автоматом блокируется! И до момента отмена блокировки другой клиент не сможет ничего записать в базу. А после записи, другой клиент если и наменял чего, то тоже не сможет записать, т.к. изменилась версия данных.
    Ну это вообще "глубочайшее" понимание 3-х звенной структуры 1С:Предприятия 8.2.
    Разница в том, что клиент не работает с базой, а работает с сервером приложений 1С, а сервер приложений работает с базой. Для серьезных систем скорость обмена между клиентом- сервером 1С и сервером 1С- сервером SQL на несколько порядков различаются. Для того и придумали сервер приложений, чтобы уменьшить объем передаваемых данных от сервера- клиенту. По этому скорость выполнения запроса и обработка результата сервером приложений в разы или даже на порядки выше чем если тоже самое будет делать клиент.
    Все зависит от конкретной системы. Если частота записи возрастает, то можно оповещать клиентов и реже. Все это можно "разрулить" разработчику, если-бы платформа 1С позволяла реализовать эту методику. Протокол WebSocket не исключает использование протокола http, а дополняет его. Разработчику решать, использовать метод "тыкания" клиента в сервер или использовать оповещение сервером клиентов. А пока платформа дает только единственный вариант работы приложения.
  17. alexburn
    Offline

    alexburn Модераторы Команда форума Модератор

    Регистрация:
    5 янв 2009
    Сообщения:
    14.735
    Симпатии:
    508
    Баллы:
    204
    Ладно, давайте зайдем с другой стороны.
    Сколько клиентов и сколько серверов????
    Клиентов может быть сколько угодно, а сервер - это хранилище, и по идее должно быть одно (бывают конечно исключения, но вам до них долеко:) )
    По делу. Вас никогда не напрягало всплывающее сообщение аськи, при просмотре кинофильма??? Хотя и это можно отключить, но тогда как я узнаю когда именно нужный мне контакт появится в сети? Ну это лирика, так сказать.
    Далее. Какой вызов сервера обработчика на клиенте??? Кто такой клиент для сервера - да нет ни кто, и зовут его никак, ни родины ни флага, сегодня он есть - завтра нет. Или, послать оповещение Васе Пупкину, правда он тормоз, и до него все доходит с третьего раза, пошлю-ка я ему три уведомления, вдруг проснется, а Машеньке - она умница все понимает с полу-слова, так что пошлю я ей половину оповещения, пусть додумывает сама, взрослая уже.
    Так что, что вы тут говорите - это пустая вода, в 1С тоже не практиканты сидят, знают за что деньги получают.
    Все что вы говорите, можно сделать и на клиенте, причем с минимальными затратами.
    Не вижу смысла дискусировать дальше. Тему предлагаю закрыть.
  18. vartanet
    Offline

    vartanet Опытный в 1С Команда форума

    Регистрация:
    16 ноя 2010
    Сообщения:
    2.698
    Симпатии:
    15
    Баллы:
    29
    прям холивар.. даешь серверно-клиентское взаимодействие!

    а меня бесит, что в objective-c только один суперкласс. хочу ксерокс, а мне придлагают наследовать либо от принтера, либо от сканера.
  19. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Провожу аналогию: web-сервер и браузеры клиентов. Кого больше? WEB-сервера+SQL (что часто-густо) не такое-же хранилище? Физически WEB-сервера и SQL-сервера также могут быть объединены в кластер. Что, на всем этом не реализуется протокол WebSocket, реализующий реальную дуплексную связь между клиентом и сервером (где не только клиент, но и сервер инициирует передачу). А по поводу напряга выскакивающего окошка- так если я не хочу принимать сообщения, я просто ухожу в offline или отключаю выскакивание окошка.
    А как думаете, в Google сидят практиканты которые придумали протокол WebSocket?! Если-бы ета идеология была утопической, нерациональной и т.п., то WebSocket (описан в документе RFC 6455) не получил-бы от IETF статус «предложенного стандарта». Следующий статус- «черновой стандарт» имеет подавляющее большинство стандартов, используемых в Интернет.
    А что касается клиента- то без клиента как раз сервер никто и зовут его никак; совершенно бесполезное скопление программно-аппаратных средств. Клиент для сервера все-равно что покупатель для продавца. Сервер обеспечивает клиента необходимыми данными, сервер для клиента формирует управляемые формы, вообще сервер существует ради клиента, а не наоборот! В версии 8.2 сервер даже запоминает сеанс пользователя. Читаем: http://v8.1c.ru/overview/Term_000000805.htm#1 раздел "Устойчивость к обрыву канала связи".
    Так кто для кого существует?
  20. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Может меня не совсем правильно понимают? Я предлагаю не поменять методику обмена между клиентами и сервером с запрос-ответ на дуплексную, я предлагаю добавить механизм дуплексного оповещения одних клиентов другими, о совершении другими клиентами определенных действий через сервер. Этот механизм разработчики могут использовать по своему усмотрению. Как к примеру захотел разработчик вместо запроса обойти элементы справочника через объектную модель- пожалуйста. И на маленьких справочниках этот метод иногда значительно увеличивает скорость работы.
    А так программно можно только получить список всех подключений к базе и вызвать отключение от базы какого-либо пользователя (при наличии на это прав). А вот послать уведомление пользователю и чтобы при этом сработал вызов определенной процедуры- нельзя.

Поделиться этой страницей