Как работают управляемые формы и тонкий клиент 1С – взгляд "из-под капота"
Переход на управляемые формы перевернул процесс разработки на 1С, заставив программистов менять привычные подходы к описанию логики работы интерфейса. Руководитель компании «Цифровой Кот» Юрий Лазаренко в своем докладе на конференции Infostart Event 2019 Inception рассказал о том, как устроены управляемые формы и как правильно работать с тонким клиентом платформы 1С:Предприятие.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Хороший материал и хорошая работа. Могу только посочувствовать по поводу костылей в "асинхронной" части ибо сам от сходных проблем страдаю.
P.S. А "Запрофцыкли" в слайдах это опечатка или какой-то ваш внутренний сленг?
P.S. А "Запрофцыкли" в слайдах это опечатка или какой-то ваш внутренний сленг?
Наш веб-клиент практически на 100% повторяет функциональность тонкого и веб-клиента 1С. При этом у него есть как слабые, так и сильные стороны – даже некоторые преимущества.
Правильно ли я понял, преимущество в том, чтобы интегрировать веб-клиент 1С в другие движки? В вашем примере с лидом - чтение данных и запись происходит через возможности вашего веб-клиента? Насколько ресурсоемки такие доработки? (интерес не праздный)
Какие еще преимущества у вашего движка?
Сколько соединений при этом проходит к 1С-серверу? Одно на каждый запрос с сайта?
(3) Верно, чтение и запись идет через нашу подсистему в режиме онлайн.
Доработки занимают обычно в 5 раз больше времени, чем разработка подобного интерфейса на управляемых формах, но может отличаться в зависимости от конкретной задачи.
Количество соединений зависит от мощности сервера (сколько http-запросов может обработать один сеанс), "веса" запросов (запрос на запись более тяжелый, чем запрос на чтение), количества запросов в период времени. При проведении тестов нам за счет переиспользования сеансов удавалось 200 пользователей повесить на один сеанс 1С. Экономия оперативки при этом была многократная. Дисковые ресурсы сэкономить так не получится. В случае использования возможностей последней версии платформы такое вряд ли прокатит, так как каждому пользователю потребуется авторизация средствами платформы, а это подразумевает создание сеанса для каждого посетителя со всеми вытекающими. Хотя мы не проверяли это, так что 100%-й уверенности нет.
Дополнительные преимущества - использование всех возможностей html и js, какие только возможны. Внешний вид может быть произвольным, не похожим на 1С совсем. Работать будет на чем угодно, включая мобилки с самым маленьким экраном.
Доработки занимают обычно в 5 раз больше времени, чем разработка подобного интерфейса на управляемых формах, но может отличаться в зависимости от конкретной задачи.
Количество соединений зависит от мощности сервера (сколько http-запросов может обработать один сеанс), "веса" запросов (запрос на запись более тяжелый, чем запрос на чтение), количества запросов в период времени. При проведении тестов нам за счет переиспользования сеансов удавалось 200 пользователей повесить на один сеанс 1С. Экономия оперативки при этом была многократная. Дисковые ресурсы сэкономить так не получится. В случае использования возможностей последней версии платформы такое вряд ли прокатит, так как каждому пользователю потребуется авторизация средствами платформы, а это подразумевает создание сеанса для каждого посетителя со всеми вытекающими. Хотя мы не проверяли это, так что 100%-й уверенности нет.
Дополнительные преимущества - использование всех возможностей html и js, какие только возможны. Внешний вид может быть произвольным, не похожим на 1С совсем. Работать будет на чем угодно, включая мобилки с самым маленьким экраном.
Автор очень аргументировано рассказывает, почему тонкий клиент быстрее, чем толстый. Ему даже веришь. Но вот вопрос : почему конфигурации на управляемых формах работают существенно медленнее, чем на обычных ? Визуально заметно, раза в полтора. И даже одну и ту же конфигурацию взять, две формы одного объекта, все равно тот же эффект. Похоже, сама платформа на управляемых формах тормозит. Вот я их и не люблю.
(7)
Об этом сказано после фразы "Итак, вывод первый:"
Тормозит не платформа - она намного быстрее тех версий, которые были во времена толстого клиента. Тормозит интерфейс - на обслуживание управляемых форм требуется больше ресурсов. И промежуточный веб-сервер скорости не добавляет. Прямой код тоже далеко не везде встречается, это один из ключевых факторов тормозов.
почему конфигурации на управляемых формах работают существенно медленнее, чем на обычных ?
Об этом сказано после фразы "Итак, вывод первый:"
Тормозит не платформа - она намного быстрее тех версий, которые были во времена толстого клиента. Тормозит интерфейс - на обслуживание управляемых форм требуется больше ресурсов. И промежуточный веб-сервер скорости не добавляет. Прямой код тоже далеко не везде встречается, это один из ключевых факторов тормозов.
Вот это – код нашего модуля, который отвечает за запись документа. Нас интересуют три строки. Первая – это, собственно, запись документа. Далее – обновление формы списка, чтобы цифры обновились. А потом закрытие формы. При синхронном варианте эти процедуры будут выполняться последовательно. Пока документ не запишется, форма списка не обновится. Пока форма списка не обновится, не закроется форма.
Это какой-то ваш велосипед. Стандартный тонкий клиент пошлёт оповещение в форму списка после записи документа, ничего не блокируется зря. Также можно вручную послать/обработать оповещение (Оповестить/ОбработкаОповещения).
(8)
Значит у нас разные стандартные тонкие клиенты. В тех, с которыми работал я, форма документа блокируется во время его записи. Поскольку запись синхронная, то и весь интерфейс блокируется следом.
Про "вручную послать/обработать оповещение" мы в курсе, но в доклад это уместить не удалось, 30 минут всего было. "Послать вручную" у нас изначально работало из коробки, но теперь, как и в случае тонкого клиента, это не стандартный способ записи объекта, потому что этот способ очень трудозатратный с точки зрения кодинга и крайне ненадежный с точки зрения достоверности системы, читайте после "Где-то забыл галочку поставить". В тонком клиенте реализовать асинхронную запись объекта на оповещениях более чем реально, но делать это есть смысл только в очень ограниченном количестве случаев по причине "очень трудозатратный".
Стандартный тонкий клиент пошлёт оповещение в форму списка после записи документа, ничего не блокируется зря.
Значит у нас разные стандартные тонкие клиенты. В тех, с которыми работал я, форма документа блокируется во время его записи. Поскольку запись синхронная, то и весь интерфейс блокируется следом.
Про "вручную послать/обработать оповещение" мы в курсе, но в доклад это уместить не удалось, 30 минут всего было. "Послать вручную" у нас изначально работало из коробки, но теперь, как и в случае тонкого клиента, это не стандартный способ записи объекта, потому что этот способ очень трудозатратный с точки зрения кодинга и крайне ненадежный с точки зрения достоверности системы, читайте после "Где-то забыл галочку поставить". В тонком клиенте реализовать асинхронную запись объекта на оповещениях более чем реально, но делать это есть смысл только в очень ограниченном количестве случаев по причине "очень трудозатратный".
А в чем преимущества дерева в связанных документах от динамического списка? Если создается новый документ, то нужно будет обрабатывать ситуацию обновления дерева. В динамических это все на уровне платформы.
Если нужна скорость, то делается вспомогательный регистр без данных и все выводиться от туда.
Если нужна скорость, то делается вспомогательный регистр без данных и все выводиться от туда.
(21) Конкретно в этом примере данные во вложенных ветках дерева меняются настолько редко, что вряд ли там произойдут изменения за время просмотра его элементов. Классический пример - дерево подчиненных документов в типовых конфигурациях, оно тоже готовится за один серверный вызов. А чтобы увидеть изменения есть кнопка "Обновить".
Есть случаи, когда использование ДС более оправдано, я об этом говорил в докладе. Основная цель включения этого пункта в доклад в том, чтобы обратить внимание, что не стоит использовать ДС там, где больше подходит другой вариант отображения информации.
Есть случаи, когда использование ДС более оправдано, я об этом говорил в докладе. Основная цель включения этого пункта в доклад в том, чтобы обратить внимание, что не стоит использовать ДС там, где больше подходит другой вариант отображения информации.
И преимущества тонкого клиента, это же сугубо прикладная задача. Все зависит от того, какие компьютеры, какие сервера... Что пользователи делают.
К примеру. 1000 пользователей, ввод заявок. Самый оптимальный вариант: тонкий клиент или http.
Или ввод и работа с маршрутами. Когда 1000 пользователей одновременно считают графы оптимальных маршрутов, а сервера не самые мощные. Все перенести на клиента и не грузить сервер подобными задачами.
К примеру. 1000 пользователей, ввод заявок. Самый оптимальный вариант: тонкий клиент или http.
Или ввод и работа с маршрутами. Когда 1000 пользователей одновременно считают графы оптимальных маршрутов, а сервера не самые мощные. Все перенести на клиента и не грузить сервер подобными задачами.