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

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

  1. vartanet
    Offline

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

    Регистрация:
    16 ноя 2010
    Сообщения:
    2.698
    Симпатии:
    15
    Баллы:
    29
    ну - вопрос не к прикладным программистам (прикладных областей стопицот), а к разработчикам платформы.
  2. ptrts
    Offline

    ptrts

    Регистрация:
    5 мар 2012
    Сообщения:
    3
    Симпатии:
    0
    Баллы:
    1
    Говорю не точно, но если мне попалась такая задачка, я бы первым делом начал копать MS BizTalk и MSMQ
  3. uza
    Offline

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

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    Если бы МНЕ попалась такая задачка, то я бы сделал примерно то, что предложил BabySG.
    А именно расписал бы суть вопроса (не КАК, но ЗАЧЕМ) на бумажке, показал бы тупиковость выбранного решения (обратный вызов? ага, клиент правда уже закрыл программу, или ушел по делам часа на три, или закрыл это окно, и уже колбасит в другом, а если и не закрыл, то что ему делать с этими 20ю ежеминутно прилетающими окнами?) и предложил бы более простое (с точки зрения технической и административной реализации) решение.

    Оно ведь конечно паровая машина - хорошо, а вот ДВЗ - компактнее, а забивать ОДИН гвоздь в ДЕРЕВЯННУЮ стену, лучше всего, как и 100 лет назад - железным молотком.
    Торговля, хоть с 2 менеджерами, хоть с 400ми - это уровень деревяных стен и гвоздей "соток". Что бы там о себе успешные менеджеры ни думали.

    P.S.
    Вот результат 6и часов работы одного такого успешного манагера
    [​IMG]
  4. BabySG
    Offline

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

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Все делают ошибки. Но, например, Вы никогда не подсматривали, как сделано в типовых? Не знаю таких людей.

    По своей же ссылке прочитайте ниже, почему некоторые браузеры отключите по умолчанию поддержку этого протокола.
    Как Вы думаете, в случае с 1С это критично? Да на все 100500% критично.

    Вы знаете, как работает описанный Вами механизм? Изучите его более внимательно.
    Также, мы рассматриваем случай, когда 1000 клиентов и всем сервер отсылает бесконечные уведомления об изменениях в остатках.
    Давайте посмотрим, что получиться:
    Вводные:
    - 1 000 000 номенклатуры на остатках
    - 500 пользователей спозиоцировались на какой-то строке из остатка
    Действие:
    - одновременно 500 клиентов изменили данные по остаткам
    События:
    -Сервер должен оповестить 500 пользователей и вычислить новое расположение текущей строки (ведь старая уже могла уйти в ноль, например).
    Вопрос:
    - Нафига такое серверу и пользователю? Ведь в следующий момент остатки ОПЯТЬ могут измениться( не забываем, что у нас 1000 клиентов!)
    В итоге мы получим постоянно скачущий список, в котором что-то меняется, но вот что - никто не знает.
    Этот пример хорошо показывает, что в общем случае задача должна быть решена по другому, ибо решение "в лоб" оказывается не только НЕ эффективным, но еще и не удобным в работе.
    Кстати, такое можно симитировать просто нагрузочным тестом и сразу поймете, в чем проблема.

    Смешали теплое с мягким. Я говорю о том, что ВСЕ РАВНО придется делать запрос к базе.
    Включите отладочные показатели и посмотрите, что происходит, когда мы делаем запрос на сервер. Обратите внимание, что просто переходит управление на сервер. Все. Никакие другие данные не гоняются (только в обратном направлении)

    Попробуйте просто псевдокодом это разрулить. Просто так, видимо, сервера ложаться от нагрузки (именно из-за того, что не так уж и проста логика распределения нагрузки)

    Еще раз: приведите РЕАЛЬНЫЙ пример использования. Все остальное - разговор в пользу бедных. Никто не будет делать серьезных изменений в логике только из-за того, что кто-то прочитал про новый протокол, но не придумал даже, как это использовать.
  5. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Проблема, описанная на Wiki датирована ноябрем 2010г. Сейчас на улице март 2012. Эта проблема давно решена и все браузеры на данный момент поддерживают этот протокол. Описание протокола: www.rfc-editor.org/info/rfc6455. Безопасность протокола обеспечивает применение механизма Web Origin, описанное в www.rfc-editor.org/info/rfc6454. Посмотреть как работает протокол можно в чате: www.mibbit.com. На сегодня протокол уже имеет статус предложенного стандарта, так что его можно полноценно использовать, что и делают целый ряд разработчиков (но не 1С).
    Любое решение должно работать в пределах определенных условий задачи. Универсальных решений не бывает. Я привел пример обновления списка остатков и цен по номенклатуре не для 500, а порядка 200 менеджеров. И я не писал что все они одновременно начинают проводить документы. Для таких случаев действительно нет смысла оповещать всех клиентов о каждом изменении. Достаточно оповестить 1 раз к примеру в 10 секунд.
    Как "это" использовать я давно придумал.
    Реальный пример приведу: менеджеры создают счета, заявки как поставщикам, так и заказчикам и ряд других документов, которые необходимо согласовывать с другими подразделениями. Менеджерам необходимо знать о факте оплаты, отгрузки, результате согласования по их документам. Решение задачи "в лоб"- запустить обработчик ожидания из глобального контекста, в процедуре обработки ожидания анализировать оплаты, отгрузки и т.п. по соответствующим документам менеджера и при необходимости открывать форму задач пользователя, на которой отображать список соответствующих событий. Главный минус данного решения в том, что даже если процедура обработки будет выполняться на стороне сервера, то 99% вызовов этой процедуры будут в пустую. Если к базе подключится 100 менеджеров и с интервалом в 60 сек. на каждом соединении будет запускаться процедура обработки ожидания, то за 1 минуту это будет уже 600 холостых циклов отработки этой процедуры с кучей запросов. Если в несколько раз увеличить время вызова обработчика ожидания, то снизится эффективность работы механизма, т.к. менеджеры не всегда сидят на месте. Бывает что прибежал менеджер в офис открыл 1С, поработал в ней 5 минут, закрыл и побежал дальше. Если интервал вызова процедуры будет 5 минут и как раз в то время, когда менеджер зашел и работает в 1С его счет проплатили, он об этом может и не узнать. Попав пару раз "в просак" с проплаченными счетами менеджеры будут в один голос кричать что система не эффективна и по старинке будут названивать по телефону в бухгалтерию и другие подразделения, ответственные за исполнение их документов.
    Другое дело когда как только проводится платежка, согласовывается документ и в этот момент заинтересованный менеджер подключен к базе, у него появляется окно со списком выполненных для него задач (практически одновременно может быть проведено и несколько платежек). Такой механизм на данной задаче на 1000% эффективнее, т.к. никогда не работает в холостую. А вот реализовать его можно только если будет возможность из одного сеанса (там где проводится платежка или другой нужный документ) оповещать другой сеанс (вызывать обработчик события в сеансе другого пользователя).
    А реализация механизма возможна при помощи 4 процедур:
    1) подписка на обработку события по оповещению о наступлении события из другого сеанса;
    2) отписка от обработки события;
    3) получение списка всех подписчиков на событие;
    4) оповещение всех или указанных подписчиков о наступлении ожидаемого события.
    Реализовать их можно и во внешней компоненте, но лучше если-бы это было реализовано платформой.
  6. vartanet
    Offline

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

    Регистрация:
    16 ноя 2010
    Сообщения:
    2.698
    Симпатии:
    15
    Баллы:
    29
    вдруг напомнило..

    был на курсах у "Габец А.П." - понял что нефига не смыслю в 1С.. ;)))

    такой "толстый троль". ;) сначала отстаивает одну точку зрения, потом резко меняет её на противоположную и уже другую отстаивает по полной.

    напомнило - потому что тема имеет чисто теоретический смысл. что сделали разработчики платформы - тем и пользуйся. не нравится - пользуйся чем-то другим. или пиши разработчикам платформы.
  7. BabySG
    Offline

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

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Список может сам раз в 10 сек обновляться.

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

    Выписку из банка заводят один раз в день. Регламентируйте этот процесс и точно будет известно, когда все платежи будут разнесены. У нас, например, к 11-00 все платежим должны быть разнесены и я точно знаю, что если я открою систему в 11-05 - я все увижу.

    Каждый раз сервер будет проверять связь с клиентом, его занятость, искать в таблице подписки... В чем отличие?

    Не один сеанс - а множество. Выписка делает движения сразу по всем документам.
    Опять промашка в логике.

    Подведем итог:
    Указанный пример без проблем решается организационно (выписка за день ОДНА) - таким образом, доработок в принципе не требуется.

    Также, как это делается, если вот прям срочно нужно всех оповестить, т.е. менеджер "убежал" (зачем тогда ему остатки, кстати?)
    - выписка делает запись в РС
    - регламентное задание проверяет записи и отсылает СМС нужным лицам.
    Все.

    Еще раз: Вы приводите те примеры, которые либо противоречат друг другу, либо решаются другими способами. Пока я не вижу како-либо необходимости в таком механизме.
    Попробуйте другой пример.
  8. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Может, а зачем? Представьте себе мобильный телефон без звонка и Вы каждые 10 секунд смотрите на его экран, чтобы узнать звонит Вам кто-либо или нет. Удобно?
    Каждый "чих" не интересует. Интересует конкретное событие. А так серверу тупо каждую секунду (а то и чаще) надо выполнять запрос, чтобы узнать произошло событие или нет. Это разве эффективно?
    См. в конце.
    "Каждый раз" по наступлению события и "Каждые 10 секунд" вообще-то отличаются и очень существенно как словами, так и заложенным в них смыслом.
    Какое множество?! У Вас что один пользователь обставлен кучей компов и одновременно на всех компьютерах постоянно запускает обработку "Банковская выписка" которая проводит все платежные поручения за день? Это чего за бред?!
    Мне сложно спорить с человеком, который никогда не видел конфигураций на платформе 8.2 и никогда не проводил технологический консалтинг в крупных компаниях (крупные это не частные предприниматели и ООО с 3-мя сотрудниками, это компании в которых работают сотни, тысячи, десятки тысяч сотрудников).
    Данное мнение складывается исходя из:
    1) В типовых конфигурациях на платформе 8.2 отсутствует документ "Выписка банка", в них есть документы "Платежное поручение исходящее", "Платежное поручение входящее", "Платежный ордер: поступление денежных средств" и "Платежный ордер: списание денежных средств". "Выписка банка" это просто обработка, формирующая список на основе указанных проведенных документов.
    2) Каждый из перечисленных в п.1 документов соответствует единичной банковской транзакции. Эти изменения в методике учета денежных средств были сделаны именно для того, чтобы прикладные решения были решениями действительно работающими в режиме РЕАЛЬНОГО ВРЕМЕНИ! Идеология единственной за день банковской выписки, проводимой утром НЕ ПРИМЕНИМА в крупных компаниях!!! В крупных компаниях за 1 день может быть произведено несколько сделок (оплат и отгрузок) с одним контрагентом. Если менеджер не будет видеть реальной картины по задолженности контрагента в любой момент времени, то такая система будет выброшена на на "помойку" еще на стадии предварительной оценки предложения по ее внедрению.

    Подведем итоги:
    1) Вы ведете разговор о работе системы у мелкого предпринимателя, у которого достаточно чтобы работала файловая версия системы (где нет даже сервера), а я изначально описывал проблемы работы системы в крупных компаниях. В мелкой организации люди сидят в одной комнате и могут без всякой системы согласовывать документы и узнавать непосредственно друг от друга о платежах и сделках. В крупной компании если пару сотен менеджеров выстроятся в очередь к бухгалтеру (или будут названивать по телефону), работающему с безналичными платежами, то вся работа рухнет.
    2) Вы предлагаете "организационно" поломать бизнес-процессы в организации, что приведет к значительному снижению эффективности работы учетной системы. Это абсолютно недопустимо, тем более что типовые конфигурации уже предполагают активную работу именно В РЕАЛЬНОМ МАСШТАБЕ ВРЕМЕНИ подсистемы учета денежных средств!
    3) Я веду речь о том, что менеджер, пока работает с системой, должен получать необходимую информацию в реальном масштабе времени, а не с задержками. Уведомление по e-mail, SMS и т.п. это хорошо, но не нужно. Можно еще "гонцов" нанять на работу, которые будут бегать по компании и разносить новости :roflmao: Речь о работе в 1С, а не задействовании сторонних средств оповещения.
    4) Вы пытаетесь отвергнуть очевидные аргументы преимущества системы, работающей по принципу обработки событий над системой примитивной циклической проверки состояния источников данных. Еще раз повторяю, принцип циклической проверки состояния источников данных нагружает сервер абсолютно бесполезной работой, в то время как эти ресурсы могут понадобится для выполнения других действительно важных задач. Попробуйте подсчитать, сколько операций к примеру в течение 1 часа нужно будет проделать серверу в случае решения на обработчике ожидания и решения на обработке событий, если в течение 1 часа может происходить от 10 до 1000 реальных событий? Причем максимальная задержка между моментом наступления события и моментом его обработки не должна превышать 10 секунд и в системе одновременно работает не менее 150 менеджеров (которых необходимо оповещать, а всего пользователей несколько сотен).
    5) Практически все современные языки программирования построены на принципе обработки событий. Язык платформы 8.2 также является событийно-ориентированным. Единственный недостаток заключается в том, что обработка событий выполняется только в пределах одного сеанса.
    6) Почитайте пожалуйста все-таки документы www.rfc-editor.org/info/rfc6455 и www.rfc-editor.org/info/rfc6454. Если сложности с английским, то в google о протоколе WebSocket. Они написаны и утверждены далеко не глупыми людьми.
  9. shurikvz
    Offline

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

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    sobenko, вот здесь - зря вы так. BabySG, пока здесь нет, появится думаю сам прокомментирует. Но думаю, что вы не правы.
  10. shurikvz
    Offline

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

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    З.Ы.
    1) Журнал документов в типовой называется "Банковская выписка". Вы поняли о чем говорит человек. Зачем придираться к словам?
    2) В режиме РЕАЛЬНОГО времени без существования регламентов у вас ничего не будет работать. Хоть есть подписка на события сервера хоть нет. Возможно у вас небольшая подмена понятий.
    Пример: допустим есть у вас эта подписка на события. ОК. Что это меняет в работе, если она не организованна, объясните? Если бухгалтер, ответственный за ввод денежных документов, вместо того чтобы делом заниматься отойдет на часок попить чай с тортиком, то менеджер ваш будет сидеть и ждать всплывающего окошка. В чем принципиальная разница: не узнает он о том что деньги пришли потому что нет этого окошка, или открыв отчет он не увидит этих денег? И так и так - он не знает что деньги эти уже на счету в банке. И при звонке клиента, с вопросом "когда отгрузка?", он точно так же будет перезванивать в бухгалтерию, и уточнять, был ли платеж. Так в чем оперативность системы, если на предприятии отсутствует организация работы? В чем будет проявляться эта работа системы в режиме РЕАЛЬНОГО времени? Работу в режиме реального времени в первую очередь обеспечивают люди, которые работают с системой, а не события с сервера.
    Еще раз: да, в приведенном примере это может повышать удобство работы, но в то же время может рассматриваться как простите "свистелка-перделка" для менеджеров которые заняты другими @$#%но важными делами которым сложно сделать пару кликов мышью. А вы предлагаете "выбросить систему на помойку", только потому что она не заточена на показ всплывающих окошек.
    .
  11. uza
    Offline

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

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    Я думаю что тролля пора сажать на диету.
  12. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Если Вы считаете что в фразах "Выписку из банка заводят один раз в день." и "Выписка делает движения сразу по всем документам." речь идет именно о классе объектов "Журнал" то подскажите пожалуйста, давно это "Журналы" стали регистраторами и начали "проводится" (создавать движения)?!
    Регламенты определяются необходимыми бизнес-процессами, действующими в организации. И бизнес-процессы в крупных и мелких организациях очень сильно отличаются. В крупных компаниях бухгалтер(а), осуществляющий импорт/экспорт платежных поручений по регламенту может выполнять эту процедуру каждые 10 минут каждого часа (если поток платежей достаточно интенсивен). Т.е. согласно регламента задержка между реальной банковсковой проводкой и проводкой в 1С не будет превышать 1 час. Более того, обмен с банками может осуществляться системой в автоматическом режиме, когда система проводит опрос банков через определенный период, а также по дополнительному запросу менеджера, если того требуют действующие бизнес-процессы.
    На помойку заказчик выбрасывает предложения о тех системах, которые не в состоянии реализовать его жизненно необходимые бизнес-процессы. Предложенный регламент (1 раз в сутки) был реализован в конфигурациях версии 7.7 и успешно "похоронен" в действующих конфигурациях версии 8.2.
    Попробуйте вникнуть в требования к учетным системам в крупных организациях, попробуйте провести пару-тройку успешных внедрений "под ключ" (не установку из коробки на 5 рабочих станций типовой, а технологический (как минимум) консалтинг с описанием положений, карт бизнес-процессов, предложений по оптимизации бизнес-процессов, составлением тех.задания и т.д.), а уж потом будете утверждать что для тех или иных сотрудников "свистелка-перделка", а что жизненная необходимость.
  13. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    А я думаю что: гуглим либы (WebSocket), курим маны (http://www.rfc-editor.org/info/rfc6455). Я думаю что не глупый народ сидит на гугле и придумывает такие протоколы. А вот как его пользовать- решать программерам.
    Я речь веду о реализации аналогичного этому протоколу механизма на платформе 1С. В 5-м посте у Вас была правильная мысль по поводу прослушки клиентом порта. Вот только платформа не позволяет пока на этот порт штатными средствами оповещение заслать и чтобы при этом на клиенте обработчик события сработал. E-Mail оно-то конечно весело, только от этого ничего не меняется, ведь E-Mail-клиент также периодически "теребит" сервер на предмет новых писем. А я о том, чтобы не "дергать" понапрасну сотне-другой клиентов сервер, когда ничего на нем не изменилось, а дергать только определенным и только когда произошли нужные события на сервере.
  14. shurikvz
    Offline

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

    Регистрация:
    1 окт 2009
    Сообщения:
    8.409
    Симпатии:
    316
    Баллы:
    104
    sobenko, речь идет о подмножестве документов, создающих движения, которые принадлежат конкретному журналу документов. О5 таки, я думаю вы прекрасно поняли о чем речь. К чему упорство?


    Замечательно. Выписки у вас заносятся в режиме условно реального времени. Так что мешает менеджеру открыть отчет в любой удобный ЕМУ момент времени, и узнать не было ли поступления денежных средств?


    Не надо передергивать и вытаскивать из контекста фразы по частям. Покажите фразу, где я сказал, что это исключительно безполезная вещь? То что в некоторых ситуация она поможет организовать бизнес процесс, не значит, что это ключевая возможность, которая нужна в каждом без исключения случае, и любая учетная система must have такую фичу. Если я начну заниматься передергиваниями, то сведу все к тому что менеджеры, следуя вашей логике, будут весь день сидеть и на ютубе клипы смотреть, пока им на пол экрана не вылезет окно "Ура! Бабки на счету! Грузите апельсины бочками...", ну а чО, никто не уведомил о поступлении денег, нах звонить клиенту, выяснять с чем связана задержка оплаты, нужно ли держать товар в резерве, вот когда окно вылезет, тогда и поработаем, да и вообще, ему же товар нужен, если надо сам позвонит.


    Разговор, насколько я понимаю, идет не о том что 1С не умеет взаимодействовать с сервером в принципе, а о том, что штатными средствами это получается не эффективно. Но ведь в принципе может, правда?
    Кроме того, у вас крупное внедрение на 100500 рабочих мест, и вы считаете штатные средства неподходящими. Да, такое может быть. Попробуйте реализовать это в виде внешней компоненты. Возможность подключения внешних компонент, ведь штатная возможность 1С, не так ли? Язык с++ для вас достаточно мощный и предоставляет достаточно возможностей (в отличие от языка и возможностей 1С), чтобы реализовать все ваши желания по протоколам-взаимодействиям? Что мешает нужный функционал реализовать данным образом (внедрение то идет уникальное, а не "на 5 пользователей из коробки"), тут ведь можно себе такое позволить? Только не надо задавать вопрос "а почему я должен писать внешнюю компоненту?".
  15. uza
    Offline

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

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    Н.Никрасов. Кому в 1С WebSocket на Руси жить хорошо.
  16. BabySG
    Offline

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

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

    Вы не спорите - Вы истерите.
    А вообще - вынужден Вас расстроить.
    У меня есть официальная благодарность от 1С за участие в проектах, мое имя звучало на семинарах 1С.
    Также, мы ведем самый большой проект по одной из типовых в России. У Вас есть такое? Тогда, видимо, у нас разное понятие о крупных компаниях. К слову - кол-во работчников в компании чуть более, чем интересно только для ЗУП, а важно, вообще-то, количество пользователей системы. Вы знаете, какие проблемы возникают при более чем 1500 пользвоателей в кластере? Нет? Тогда о чем мы говорим...

    Ага, поэтому крупные корпорации постоянно проводят оптимизацию организационных вопросов :)

    Еще раз:
    По Вашему на каждое событие сервер должен производить поиск подписчиков, искать - "а доступен ли сейчас клиент", ждать подтверждения о том, что клиент получил оповещение, отметить событие доставленым. Опустим тот вопрос, что должно произойти, если клиент не в сети (подумайте над этим, кстати.)
    Далее: все та же пресловутая выписка - в одном документе выписки есть десяток документов, оплату которых мы ждем. Таким образом, сервер должен 10 раз достучаться до клиента (со всеми прочими накладным расходами)
    Предложеный метод:
    Требует ОДНОГО обращения к серверую. Накладных расходы минимизированы за счет того, что клиент сам знает, что ему нужно и сервер должен просто обработать запрос.
    Клиент не является привязанным к серверу, когда он оффлайн. (Пимер аськи - Вы забыли закрыть окно и уехали домой. Все оповещения продолжают поступать в окно, которое открыто на офисном компе. По приезду домой этих сообщений Вы не увидите)
    Как собираетесь это разруливать?
    Вы все пытаетесь принянуть за уши сокеты, которые решают ДРУГУЮ задачу, хоть и похожую. Но там априори тот факт, что клиент все время онлайн. А у нас пользвоатель может запустить систему с другого рабочего места.

    Ага, а так клиент должен знать о всех других клиентах. Смешно.

    Читайте выше - это другая задача.

    И правильно, что не позволяет. Сразу видно, что у Вас "типовая из коробки" :)
    Расскажите, как будет работать схема, когда поднят кластер с дополнением из резервном кластера с балансировкой нагрузки?
    Да у Вас отчеты на СКД могут на разных серверах отрабатывать!


    Подводя итог:
    1. Вы ничего не знаете обо мне и в каких проектах я участвовал/участвую
    2. Пытаться мериться пись...ми со мной бесполезно - проиграете :)
    3. Описанные задачи частично решаются чисто организационным методами, не требующих никаких затрат. Ознакомьтесь с литераторой на этот счет и потом поговорим.
    4. Вы так и не привели РЕАЛЬНОЙ задачи, которая ТРЕБУЕТ взаимодействия сервер->клиент. Задача с выпиской решается за 5 сек, что несколько человек Вам уже объяснило.

    Поэтому предлагаю прекратить тут истерику и, если уж Вы действительно хотите понять, почему мы считаем, что такое взаимодействие только усложнит ситуацию, более плотно разобрать пример с выпиской.
    Давайте определим какую конфигурацию мы берем за пример и Вы опишите, что же должно происходить (подробно опишите, вполь до того, что должно происходить, когда отваливается клиент без оповещения сервера об этом) Думаю, что уже в процессе написания этой схемы Вы поймете все сложности и проблемы, по которым эта схема становиться весьма тяжеловесной и не имеющей смысла уже только на такой простой задаче.
  17. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Это не упорство. Неверное именование предметов разговора приводит к совершенно иному пониманию смысла изложенного. У любого разработчика, работавшего с первых версий 1С Бухгалтерии словосочетание "Банковская выписка" однозначно ассоциируется с одноименным документом. В изложенном BabySG контексте именно о таком документе он и говорит, а ни как не о подмножестве банковских документов.
    Я не однократно на проектах сталкивался с идеями других внедренцев в стиле "вот проведите этот документик, затем еще пару-тройку, а чтобы посмотреть на результат Вы должны открыть и сформировать вот этот отчетик". В 99% случаев клиенты отвечали "нет, спасибо нам такое "чудо" не надо! До свидания!". Любая система должна быть максимально удобной для пользователя. А Вы предлагаете менеджеру постоянно формировать отчет о поступлении денежных средств. Да это решение еще хуже чем реализация на обработчике ожидания!
    И не стоит забывать что движения по банку это только небольшая часть документов. Есть еще масса документов, которые менеджер отправляет на согласование и т.п.
    А я и не вел разговор что механизм подписки на события от из сеансов нужен везде и поголовно. Я речь с самого начала задал вопрос о том, можно-ли как-то реализовать такой механизм, затем привел примеры где он может применяться, а уж потом пошли споры о том, что он никому кроме меня не нужен.
    Я не против внешней компоненты, но надежнее реализовать в платформе.
  18. alexburn
    Offline

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

    Регистрация:
    5 янв 2009
    Сообщения:
    14.767
    Симпатии:
    509
    Баллы:
    204
    sobenko, вы получили ответ на свой вопрос?
  19. BabySG
    Offline

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

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Уточните конфигурацию. В разных конфигурациях этот документ делает немного разное. В УТ11, например, он сразу двигает взаиморасчеты.

    С конфигурацией Документоборот знакомы? Там все работает и никто не жалуется.

    Сделать можно все, но зачастую это не имеет экономического/любого другого смысла

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

    Других вариантов я не припомню, честно говоря.
    Кстати, рекомендую ознакомиться, как работает фоновое формирование отчетов СКД. Ваш случай, который реализован в платформе :)
  20. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    "Я Вам про Фому, а Вы мне про Ерему..."
    Протокол WebSocket я упоминал в двух контекстах:
    1) как о самой идее реализации асинхронного обмена между клиентами и сервером (к стати какой-нибудь WEB- ресурс также может быть реализован в виде кластера, в который входит множество физических серверов, но это ни как не мешает работать протоколу). Проще говоря о самом механизме взаимодействия, который как нельзя к стати подходит для реализации прикладного решения на платформе 1С.
    2) как о протоколе, который может быть задействован в случае реализации механизма асинхронного обмена для тонкого клиента, работающего через браузер.

    Я не писал, что механизм асинхронного обмена должен полностью заменить механизм синхронного (запрос-ответ) обмена между клиентами и сервером. Я писал о том, что в ряде случаев этот механизм позволил-бы повысить эффективность работы прикладного решения во много раз за счет значительного уменьшения бесполезных циклов запросов.

    Я привел пример, с условием что НЕОБХОДИМО (это задача заказчика и не обсуждается организационное решение) реализовать задачу своевременного оповещения пользователей о появлении у них новых задач (а не только уведомлений о проведенных платежках). Именно в этом случае механизм асинхронного обмена намного эффективнее механизма, реализованного на обработчике ожидания. А Вы мне твердите что надо менять бизнес-процессы в организации.

    Перечитайте пожалуйста еще раз всю тему и все мои посты. Я еще раз повторяю, что в случае, когда в течение определенного интервала времени (который устанавливается программно разработчиком прикладного решения) происходит более одного события, подписавшийся клиент оповещается о событии только один раз (только один раз у него вызывается процедура обработки события)!

    Я не вижу смысла обсуждать проблемы, которые возникают при обрывах связи между клиентом и сервером, т.к. они и так уже решены платформой. Простой пример- клиент послал запрос серверу и "отвалился". Что делает в этом случае сервер? Куда возвращается ответ? Сервер всегда знает, кто в Online, а кто в Offline находится. Цитата из обзора платформы, отказоустойчивость:
    "Кластер (а не сервер!) «запоминает» подключившихся пользователей и состояние выполняемых ими действий благодаря тому, что для каждого пользователя создается собственный сеанс. В случае потери физического соединения кластер будет ожидать восстановления соединения с этим пользователем. В подавляющем большинстве случаев после восстановления соединения пользователь сможет продолжить работу с того «места», на котором она была прекращена. При этом не потребуется повторное подключение к информационной базе."
    Может и эту цитату из первоисточника станете опровергать?!

    Я Вас невероятно удивлю еще тем, что любой клиент МОЖЕТ знать о том, какие пользователи в данный момент подключены к базе как программно (функции ПолучитьСеансыИнформационнойБазы() и ПолучитьСоединенияИнформационнойБазы()), так и с помощью встроенной формы "Список активных пользователей". По этому Ваша фраза "Ага, а так клиент должен знать о всех других клиентах. Смешно." действительно смешна. Не должен, а может получить массив всех сеансов, когда это необходимо.

    И еще одна Ваша проблема в том, что наименования Вы используете как-то неопределенно. Что Вы имеете в виду под термином "Банковская выписка"? У меня создалось впечатление что это документ, а Вы какой объект имеете в виду? Если так, то я писал о документах платежное поручение и платежный ордер!

    Я так понимаю, что Вы так и не поняли о чем я пишу. Поясню еще раз.
    Идея механизма асинхронного взаимодействия между кластером 1С и клиентами состоит в том, что программно выполняется подписка на определенное событие не в пределах текущего сеанса, а в пределах всей базы. При подписке также указывается минимальный интервал времени между вызовами процедуры обработки события (для исключения описанной вами проблемы- вызова 1000 раз обработчика в течение 1 сек.). Также может быть задана либо процедура оповещения, в которой можно более тонко описать в каких случаях и какие сеансы необходимо оповестить о наступлении события, либо при подписке на событие указывается фильтр (какие именно изменения значений измерений, ресурсов, реквизитов и т.п. объектов вызывают процедуру обработки события на клиенте).
    Этот механизм не исключает реализованное синхронное взаимодействие (запрос-ответ) между клиентом и кластером, а дополняет его, позволяя исключить бесполезные циклические запросы к базе.
    На случай, когда клиент запускает приложение я и так могу сформировать необходимые запросы и получить список всех невыполненных задач пользователя, при открытии какого-либо списка (задач, документов, справочников, записей регистра и т.п.) и так платформа формирует запросы, получая необходимое число элементов для отображения формы списка. Вопрос в том, что этот список сейчас может обновляться только либо принудительно (нажатием кнопки "Обновить" или программно), либо периодически (установкой интервала обновления формы списка). Вот это не всегда правильно, т.к. частое обновление списка ведет к избыточному возрастанию количества запросов, а редкое обновление дает не актуальную информацию.

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

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