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

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

  1. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Пока на этот уровень углу*****ся не вижу смысла, т.к. Вы не освоили даже общую схему взаимодействия на уровне Клиент-Сервер. Под термином "Клиент" я имею в виду клиентскую оболочку платформы (или браузер), а под термином "Сервер"- серверную часть. Когда на клиентской части (с использованием оболочки толстого или тонкого клиента) настраивается подключение к базе, то там указывается "Сервер" и "Имя базы" (для клиент-серверной базы). Каким образом организован кластер на сервере (с резервными кластерами, списком серверов, активных и резервных процессов) я пока не разбираю. Рано туда пока углу*****ся.
    Вы называете #Если КЛИЕНТ директивой?! Может прочтете все-таки сами документацию. Там черным по белому написано (даже в синтаксис-помощнике в разделе "Общее описание языка") что это ИНСТРУКЦИЯ ПРЕПРОЦЕССОРУ! И кто из нас путает понятия?
    Так вот инструкции препроцессору указывают какие части текста должны быть скомпилированы на сервере, а какие на клиенте. Инструкции могут "вырезать" скомпилированного модуля как полностью определенные процедуры и функции, так и их части. В результате одна и та-же процедура может по разному отрабатывать на стороне сервера и на стороне клиента. Инструкции используются для общих модулей и модулей объектов.
    А вот директивы используются для модулей форм, команд, общих модулей управляемого приложения. Предваряют описания процедур или функций и указывают кто (клиент или сервер) их выполняет.
    Именно так написано в документации!
    Я не умнее всех. А решать проблемы платформы при некорректном завершением работы на клиенте должны не партнеры, а разработчики платформы 1С. Это их работа. Если-бы 1С выкладывала весь код платформы и структуру баз на SQL-серверах у себя на сайте, то можно было-бы обсуждать и переписывать платформу. А так платформа закрыта и даже в структуру базы по лицензионному соглашению лазить ЗАПРЕЩЕНО! По этому не вижу смысла обсуждать работу "черного ящика", в который я не могу "заглянуть".
    Я нормально общаюсь с разработчиками, т.к. они сначала читают, вникают, а потом отвечают не занимаясь подменой понятий, монтажом отдельных частей моих фраз и т.п.
  2. TopicStarter Overlay
    sobenko
    Offline

    sobenko

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

    Реализуем через обработчик ожидания. Что получается: для обработчика надо задать интервал 10 секунд. За 1 час процедура обработчика на 200 клиентах отработает 3600/10*200=72000 раз. Реально пользователи получат нужное оповещение только в 6*200=1200 случаях. Эффективность работы по такому принципу: 1200/72000*100=1,67%. 98,33% процедура будет работать в холостую.
    Увеличение интервала ожидания до 60 секунд приведет что если в течение последней минуты работы пользователя появятся все 6 задач (или даже одна), то он успешно их пропустит. Убежав решать другие дела он затормозит (возможно очень важные) бизнес-процессы. Придется переадресовывать задачи другим испонителям (к примеру начальникам), чему они не очень будут рады, когда увидят что задача появилась тогда, когда первый ее получатель еще работал в системе. Можно "прикрутить" еще SMS-уведомления, но это дополнительный "вертолет", который тоже не очень надежен.

    Реализация по моему методу даст эффективность работы подсистемы 100% (т.к. пользователи будут получать уведомление сразу при появлении задачи или максимум через 10 секунд, при появлении нескольких задач в течение 10 секунд после первой). Холостых запусков процедуры обработки события оповещения просто не будет. Нагрузка на сервер соответственно будет минимально необходимой.

    Я уже молчу, если пользователям необходимо в реальном масштабе времени обновлять форму списка цен на номенклатуру. Будет до минимума снижена вероятность что менеджер по телефону сообщит старую цену на товар.

    Это на первый взгляд "бантики-рюшечки", но когда начинаются "разборы полетов", то виновата оказывается система, которая не обеспечивает требуемой достоверной информацией. Вывод руководства: система плохая надо искать новую.
  3. BabySG
    Offline

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

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

    Хорошо, я ошибся в написании. И что? Суть изменилась?
    Еще раз: смысл делать подписку с клиента для вызова функции сервера с источником события - сервер? Вам само-то не кажется это странным?

    Приведите, пожалуйста, ссылки на партнерский, где Вы там общаетесь.
    Сергей Нуралиев первое что спросит: какая прикладная задача? Ответьте на этот вопрос.
  4. BabySG
    Offline

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

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Вообщо-то, я уже написал про это.
    И, еще раз: Вы ОПЯТЬ путаете РЕШЕНИЕ с ЗАДАЧЕЙ. А меня есть именно задача, но РЕШЕНИЕ у меня совершенно ДРУГОЕ, нежели описанное Вами.
    Поэтому у меня работает все достаточно быстро (APDEX показывает отличные результаты, например)

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

    Платформа разработана для учетных задач. Остальное вторично. Поэтому, несмотря на то, что можно написать некое подобние аськи - это не является задачей платформы и путем для ее развития.
    Это разработчиками неоднократно подчеркивалось.
    Исходя из этого: платформа не предназначена для приложенией аля аська.

    И что? В чем проблема-то? Еще раз: изучите данную проблему по методике APDEX и Вы поймете, что основной источник прблем находиться совершенно в другом месте.

    Т.е. смс -> ненадежна, использвоать не будем, а вот платформа не надежна - но использовать будем?

    Нагрузка на сервер будет значительно выше - уже устал объяснять очевидное.
    Ибо "холостой" запуск процедуры выполняется намного быстрее, чем пара проверок на "подписки".

    И правильно, что молчите.
    Ведь эта задача, опять-таки, не решается таким способом.
    Итак (предположим, что у нас мгновенное обновление)
    1. Звонок клиента
    2. Сообщаем цену
    3. Вешаем трубку
    4. В этом момент маркетолог меняет цену
    Ну и чем тут поможет мгновенное оповещение? Менеджер срочно будет перезванивать? Бред же.

    Описанные примеры, которые, по Вашему, требует изменений в платформе показывают следующее:
    1. Организационные проблемы в компании
    2. Слабое знание учетных процессов и принципов построения структуры хранения данных
    3. Попытка решение задач "в лоб", когда есть иные решения

    Да, кстати, я меня очень плотный график и по первой писульке от Вас бежать на форум и смотреть, что же в очередной раз объяснять надо - нет никакого желания.
    Я итак отписываюсь по инерции, ибо написал неоднократно: реальная задача где? Где прикладная задача, которая требует такого решения? Вы даже придумать ее не можете...
    Поэтому в личку можно мне не писать, как и другим модераторам.
    Как Вы правильно заметили, я тут администратор и у меня другие задачи, чем пытаться придумать сферического коня в вакууме.

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