0

Вызов клиента с сервера 1с

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.11.2867.

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

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

Основные возможности и сценарии

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

В клиентское приложение вы можете передавать данные, имеющие XDTO-сериализацию. Естественно типы передаваемых данных должны быть доступны на клиенте. Вы можете использовать передачу информации с сервера в клиентское приложение в самых разных сценариях. Например:

  • Для отображения прогресса длительной серверной операции;
  • Для уведомления пользователей о перезагрузке сервера и принудительного завершения клиентских приложений;
  • Для уведомления пользователя о входящем SIP-звонке;
  • Для поддержки прохождения бизнес-процессов;
  • Для реализации «напоминалок», уведомлений и пр.

Пример использования

Проще всего объяснить новый механизм на конкретном примере, когда длительная операция, выполняемая на сервере, состоит из нескольких этапов. По мере выполнения очередного этапа вы хотите извещать клиентское приложение об этом. Чтобы клиентское приложение некоторым образом показывало пользователю ход выполнения этой операции.

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

Дальше начинаются нюансы. Если ваша задача предполагает, что все клиентские приложения должны каким-то образом автоматически реагировать на информацию, поступающую с сервера, тогда вы можете создать единственное служебное сообщение, и добавить в состав его участников специальный идентификатор, обозначающий всех пользователей. Такой идентификатор можно получить с помощью нового типа СтандартныеПользователиСистемыВзаимодействия.ВсеПользователиПриложения. В таком обсуждении сообщения будут доставляться всем пользователям системы, и тем, которые есть сейчас, и тем, которые появятся в будущем.

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

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

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

Правды ради нужно сказать, что от имени одного пользователя может быть запущено несколько приложений. Но сути дела это не меняет. Если информацию с сервера нужно передать в то приложение, которое инициировало серверную операцию, эффективнее использовать отдельные служебные обсуждения для каждого пользователя, чем «пулять» по всем клиентам в одном общем служебном обсуждении. В этом случае ресурсы сервера взаимодействия будут использоваться бережнее, а нагрузка на него будет меньше.

Итак, для каждого пользователя нужно создать своё служебное обсуждение. Это можно представить следующей схемой:

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

Процедура СоздатьСлужебноеОбсуждение(КлючСлужебногоОбсуждения) Экспорт Если СистемаВзаимодействия.ПолучитьОбсуждение(КлючСлужебногоОбсуждения) = Неопределено Тогда Обсуждение = СистемаВзаимодействия.СоздатьОбсуждение(); Обсуждение.Отображаемое = Ложь; Обсуждение.Ключ = КлючСлужебногоОбсуждения; Обсуждение.Участники.Добавить(СистемаВзаимодействия.ИдентификаторТекущегоПользователя()); Обсуждение.Записать(); КонецЕсли; КонецПроцедуры Функция КлючСлужебногоОбсуждения() Экспорт Возврат "Сообщения сервера " + СистемаВзаимодействия.ИдентификаторТекущегоПользователя(); КонецФункции

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

Ещё одно новое свойство обсуждения будет вам полезно – Отображаемое. Для служебных обсуждений его лучше устанавливать в Ложь, тогда они не будут показаны в пользовательском интерфейсе.

Итак, создание служебного обсуждения это действие, которое нужно сделать один раз, при создании нового пользователя. А вот что нужно делать при каждом запуске клиентского приложения, так это подписываться на служебное обсуждение, предназначенное текущему пользователю. Для этого менеджеру системы взаимодействия мы добавили новый метод НачатьПодключениеОбработчикаНовыхСообщений():

&НаКлиенте Процедура ПодписатьсяНаСлужебноеОбсуждение(КлючСлужебногоОбсуждения) Экспорт ОшибкаПодключения = Новый ОписаниеОповещения( , , , "ОшибкаПодключения", СообщенияКлиент); ОбработкаСообщенийСервера = Новый ОписаниеОповещения("ОбработкаСообщенийСервера", СообщенияКлиент); СистемаВзаимодействия.НачатьПодключениеОбработчикаНовыхСообщений(ОшибкаПодключения, КлючСлужебногоОбсуждения, ОбработкаСообщенийСервера); КонецПроцедуры &НаКлиенте Процедура ОбработкаСообщенийСервера(Сообщение, ДополнительныеПараметры) Экспорт . &НаКлиенте Процедура ОшибкаПодключения(ДополнительныеПараметры) Экспорт .

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

Теперь вы можете на сервере отправить сообщение в служебное обсуждение, и приложение, подписанное на это обсуждение, автоматически его обработает.

В настоящее время в Библиотеке стандартных подсистем (БСП) реализован механизм выполнения длительных операций на сервере, который использует фоновые задания. Это позволяет распараллелить исполнение прикладного кода на сервере и освободить пользовательский сеанс.

Читайте также:  Вай фай приемник usb

В этом примере необходимо использовать ту же самую механику.

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

Тут желательно учесть ещё один момент. От имени одного и того же пользователя может быть одновременно запущено несколько клиентских приложений. Все они подписаны на служебное обсуждение этого пользователя. Значит, все они отреагируют на сообщение, которое появится в этом обсуждении. А это нехорошо.

Поэтому при запуске фонового задания желательно снабдить его уникальным идентификатором, который передать в само фоновое задание, и кроме этого вернуть на клиента. Тогда клиент будет знать «свои» фоновые задания, а фоновое задание, посылая сообщение, сможет однозначно себя идентифицировать.

Запуск фонового задания может выглядеть таким образом:

&НаКлиенте Процедура ОбработатьДанные(Команда) // Запустить фоновое задание. ИдентификаторЗадания = ОбработатьФоновымЗаданием(КлючСлужебногоОбсуждения); // Запомнить идентификатор запущенного задания в глобальной клиентской переменной. ИдентификаторыЗаданий.Добавить(ИдентификаторЗадания); КонецПроцедуры &НаСервереБезКонтекста Функция ОбработатьФоновымЗаданием(КлючСлужебногоОбсуждения) // Создать идентификатор фонового задания, чтобы: // – передать его в само задание, // – вернуть его на клиента. ИдентификаторЗадания = Строка(Новый УникальныйИдентификатор); Параметры = Новый Массив; Параметры.Добавить(КлючСлужебногоОбсуждения); Параметры.Добавить(ИдентификаторЗадания); ФоновыеЗадания.Выполнить("СообщенияСервер.ОбработатьДанныеНаСервере", Параметры); Возврат ИдентификаторЗадания; КонецФункции

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

А длительная операция, выполняемая на сервере, может выглядеть так:

Процедура ОбработатьДанныеНаСервере(КлючСлужебногоОбсуждения, ИдентификаторЗадания) Экспорт // Получить обсуждение, т.к. его идентификатор понадобится для создания сообщений. СлужебноеОбсуждение = СистемаВзаимодействия.ПолучитьОбсуждение(КлючСлужебногоОбсуждения()); // Создать структуру данных для передачи её в сообщении: // – ИдентификаторЗадания – чтобы клиент мог определить, его ли это фоновое задание // – Значение – значение, которое надо обработать на клиенте // – СпособОбработки – способ, которым надо обработать значение // (отобразить в индикаторе, показать как текст и т.д.) СтруктураДанных = Новый Структура; СтруктураДанных.Вставить("ИдентификаторЗадания", ИдентификаторЗадания); СтруктураДанных.Вставить("Значение", 0); СтруктураДанных.Вставить("СпособОбработки", "Индикатор"); // Длительный алгоритм, состоящий из 100 этапов. Для Счетчик = 1 По 100 Цикл // Сообщение клиенту. СтруктураДанных.Значение = Счетчик; Сообщение = СистемаВзаимодействия.СоздатьСообщение(СлужебноеОбсуждение.Идентификатор); Сообщение.Данные = СтруктураДанных; Сообщение.Записать(); КонецЦикла; // Сообщение о завершении фонового задания. СтруктураДанных.СпособОбработки = "НеОтслеживать"; Сообщение = СистемаВзаимодействия.СоздатьСообщение(СлужебноеОбсуждение.Идентификатор); Сообщение.Данные = СтруктураДанных; Сообщение.Записать(); КонецПроцедуры

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

И, наконец, на клиенте процедура, обрабатывающая новые сообщения, может выглядеть так:

&НаКлиенте Процедура ОбработкаСообщенийСервера(Сообщение, ДополнительныеПараметры) Экспорт // Наше ли фоновое задание. ИндексЗадания = ИдентификаторыЗаданий.Найти(Сообщение.Данные.ИдентификаторЗадания); Если НЕ ИндексЗадания = Неопределено Тогда // Как обрабатывать это сообщение. Если Сообщение.Данные.СпособОбработки = "Индикатор" Тогда Состояние("Выполняется обработка данных", Сообщение.Данные.Значение); ИначеЕсли Сообщение.Данные.СпособОбработки = "НеОтслеживать" Тогда ИдентификаторыЗаданий.Удалить(ИндексЗадания); КонецЕсли; КонецЕсли; КонецПроцедуры

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

Заключение

Как вы видите механизм довольно гибкий. И это позволяет использовать его для самых разных задач. Приведённый пример это лишь один из сценариев, как говорится, «в лоб».

Существуют и другие, более изощрённые сценарии. Например, когда длительная операция (загрузка данных) инициируется одним из пользователей, а известить о ходе её выполнения нужно группу пользователей, которые с этими данными работают.

Другая область задач связана с тем, что информация не просто доставляется в клиентское приложение, а сервер некоторым образом «отдаёт команды» приложениям, заставляя их выполнить те или иные действия. Например, обновить итоговые данные, отображаемые в отдельном окне, или схему выполнения некоторого глобального прикладного процесса. Или корректно завершить работу клиентского приложения, если администратору системы нужно перезагрузить сервер, а пользователя нет на рабочем месте.

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

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

  1. Напомним, что существуют 4 директивы компиляции, включающие «клиента», «сервер», «сервер без контекста», «клиент на сервере без контекста». В нашем примере мы будем рассматривать 1С: Предприятие 8, функционирующее в клиент-серверном режиме. Мы не принимаем во внимание работу с БД и данными, а также различными нюансами системы. Теперь рассмотрим непосредственно серверный вызов.
  2. Серверный вызов является передачей конкретного блока информации от клиента на сервер. Целью передачи данных является получение некоторых сведений. Первый вызов происходит в момент старта работы с 1С. Получить доступ к базе данных можно только с помощью сервера, в то время как соединение всегда имеет строгую пропускную способность. Это объясняется необходимостью экономии трафика, так как соединение может происходить по каналу, имеющему низкую скорость передачи информации. Теперь рассмотрим особенности функционирования системы, предварительно определив 3 важных пункта:
  • Процесс, связанный с клиентской частью.
  • Процесс, связанный с серверной частью.
  • Собственно серверный вызов.

Клиент-серверная архитектура 1С

3. Клиентская часть запускается на компьютере и способна генерировать серверный вызов. Процесс, связанный с серверной частью, происходит непосредственно на сервере 1С, отслеживает все клиентские сеансы и может взаимодействовать с ними. Работу с клиентской частью сервер производит исключительно через серверный вызов. Сам серверный вызов производит транспортировку информации для клиента и сервера. Далее рассмотрим сами особенности, начиная с открытия формы данных.

4. Когда пользователь нажимает кнопку развертывания формы, управление передается непосредственно на сервер. Получая параметры, которые необходимы для создания данных из БД, производится подготовка контекста, который передается в дальнейшем клиенту. Говоря простыми словами, пользователь дает запрос, инициируя серверный вызов, а он, в свою очередь, соединяясь с сервером, получает данные для клиента и передает ему. Если, например, пользователю понадобится отправить форму с контекстом, то она в том же виде придет на клиентскую часть от сервера. Но можно ограничиться передачей информации только с указанными параметрами, тогда сервер выдаст результат, исходя из определенных параметров. Это помогает избежать лишней нагрузки на сервер, поэтому часто директива «на сервере без контекста» является более предпочтительной, чем «на сервере».

Читайте также:  Жестокие русские народные сказки

5. Когда необходимо выполнять одну и ту же обработку, можно воспользоваться кодом и разместить его как самостоятельную процедуру. Данная процедура будет иметь вид копирования, размещать ее нужно на сервере в соответствующей директиве «На сервере без контекста». Чтобы оптимизировать процедуру (избежать лишней нагрузки), можно воспользоваться более сложной директивой «На клиенте на сервере без контекста». Так мы получаем процедуру копирования для клиентской и серверной части. Таким образом, мы избавляем себя от необходимости делать лишние серверные вызовы.

6. В этой статье мы разобрали особенности серверного вызова и подчеркнули, что выбор корректной директивы позволяет увеличить скорость отправки информации. Рекомендуется не выполнять передачу контекста на сервер, снизить число серверных вызовов, запускать ресурсоемкие задачи на сервере. Так вы снизите нагрузку и сэкономите время.

Видео: Оптимизация клиент-серверного взаимодействия

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

Это будет полезно начинающим разработчикам и тем, у кого есть пробелы в области клиент-серверного взаимодействия – всё объясним «на пальцах» 🙂

Клиент-серверная архитектура заложена в платформе изначально – со времен «1С:Предприятие 8.0».

Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере.

Всё изменилось с выходом платформы «1С:Предприятие 8.2», когда появился тонкий клиент. Теперь на клиенте доступен один функционал, на сервере – другой. Клиент и сервер «общаются» между собой с помощью серверного вызова.

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

Немного базовой теории

Перед тем, как перейти к содержательной части, договоримся о некоторых ограничениях:

  • Мы подразумеваем, что Вы знаете о существовании четырёх директив компиляции, доступных в модулях формы: «&НаКлиенте», «&НаСервере», «&НаСервереБезКонтекста» и «&НаКлиентеНаСервереБезКонтекста».
  • Все примеры будут опираться на работу «1С:Предприятие 8» в клиент-серверном режиме. Файловый вариант по сути является эмуляцией клиент-серверного режима, с небольшими отклонениями (для данной статьи это не критично)
  • В рамках этого материала рассматривается исключительно взаимодействие клиента и сервера 1С. Работа с базой данных, преобразование данных и прочие нюансы работы системы – это темы других статей.

Далее, освежим в памяти немного теории.

Директивы, в имени которых упоминается «Клиент», устанавливают ограничение на обращение к базе данных.

Процедуры или функции, написанные под директивой «Без контекста», не имеют доступа к контексту (данным) формы. Исходя из этой информации, легко представить ограничения директив по доступу к данным в виде следующей таблицы:

Директива Данные формы База данных
&НаКлиенте +
&НаСервере + +
&НаСервереБезКонтекста +
&НаКлиентеНаСервереБезКонтекста

Опережая вопрос «Для чего же директива с самым длинным названием, если она ограничивает и использование контекста форм, и обращения к базе данных?», напомню: любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.

Отсюда делаем вывод: у методов, описанных под директивой «&НаКлиентеНаСервереБезКонтекста», единственным источником данных являются эти самые переданные параметры.

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

  • &НаКлиенте
  • &НаСервере
  • &НаСервереБезКонтекста
  • &НаКлиентеНаСервереБезКонтекста.

То есть из метода, описанного под директивой «&НаКлиенте», можно вызывать процедуры и функции, описанные под любой директивой. А вот «из-под» директивы «&НаСервереБезКонтекста» можно вызывать только то, что описано под директивой «&НаСервереБезКонтекста» или «&НаКлиентеНаСервереБезКонтекста».

Теперь про серверный вызов

Серверный вызов – это передача какой-то информации с клиентской части «1С:Предприятие 8» на серверную часть с целью вернуть обратно некий набор данных.

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

«Оу! При чём тут Библиотека?!» – спросите Вы.

Всё очень просто:

Обратите внимание, что доступ к базе данных есть только на серверной части, а соединение между клиентом и сервером имеет ограниченную пропускную способность. Это и неудивительно – ведь соединение между клиентской и серверной частью может быть установлено даже по нестабильному низкоскоростному каналу связи (например, посредством мобильного интернета).

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

Но, для того чтобы перейти к основной теме данной статьи, необходимо сначала разобраться – где будет выполняться программный код, написанный под определенными директивами. То есть на какой части приложения «1С:Предприятие 8» будут доступны процедуры и функции, описанные под директивами «&НаКлиенте», «&НаСервере», «&НаСервереБезКонтекста» и «&НаКлиентеНаСервереБезКонтекста»:

Видим, что на стороне клиента у нас будут доступны процедуры и функции, написанные под двумя директивами из четырёх, а на стороне сервера – под тремя из четырёх.

Сразу возникают вопросы: «Зачем такое многообразие и чем оно полезно?», «Как метод, описанный под директивой «&НаКлиентеНаСервереБезКонтекста» может выполняться и на клиенте, и на сервере?».

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

И в этом нам помогут наши новые друзья, знакомьтесь!

Читайте также:  Диапазон каких частот используется в wi fi

Итак, давайте рассмотрим несколько особенностей работы программного кода в «1С:Предприятие 8», написанного под разными директивами.

Действие 1. Открытие пользователем формы с данными.

Действие 2. Получение из открытой Пользователем формы дополнительных данных из Базы данных.

Получение этих данных может быть описано под двумя директивами – «&НаСервере» и «&НаСервереБезКонтекста». Рассмотрим оба случая.

Явление 1. Директива «&НаСервере»

После выполнения метода на сервере, весь этот «пакет» транспортируется обратно. Таким образом, форма со всеми элементами и данными дважды проходит через самое узкое место системы.

Явление 2. Директива «&НаСервереБезКонтекста»

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

Из примеров видно, что далеко не всегда оправдано указание директивы компиляции «&НаСервере» с точки зрения использования контекста (данных) формы на сервере.

Если возможно решить возникшую задачу путём отправки на сервер только определённого набора данных, то надо эту возможность использовать и описывать метод под директивой «&НаСервереБезКонтекста». Это позволит уменьшить нагрузку на серверный вызов, а также не занимать сервер обработкой и хранением ненужной в текущий момент информации.

До этого момента при каждом изменении свойства «Видимость» происходил серверный вызов, как при использовании директивы «&НаСервере».

Но использование директивы «&НаСервереБезКонтекста» не является панацеей. Помимо нагрузки на серверный вызов, всегда необходимо задумываться ещё над одним параметром.

Действие 3. Обработка данных табличной части формы с получением дополнительной информации из Базы данных.

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

Мы уже знаем – лучше использовать директиву «&НаСервереБезКонтекста».

Явление 2. Предварительная обработка табличной части на стороне клиента с целью подготовки требуемых к обработке на сервере данных и «упаковки» их в набор параметров. Затем передача этого набора на сервер для получения дополнительной информации из базы данных.

Используем всё ту же директиву «&НаСервереБезКонтекста».

Большое количество текущих серверных вызовов может свидетельствовать о неоптимальном программном коде.

Избегайте создания серверных вызовов внутри цикла. Подготовьте набор параметров и единожды выполните его передачу для обработки на сервер. Если предполагается сложная обработка большого количества данных формы – передайте её полностью на сервер (при помощи директивы «&НаСервере») и выполните все действия на стороне сервера.

С директивой «&НаСервереБезКонтекста» вроде бы разобрались. Она нужна для того, чтобы уменьшить объем информации, передаваемой в рамках одного серверного вызова. Дополнительно разобрались с количеством текущих серверных вызовов – необходимо стремиться к их минимизации.

Давайте теперь попробуем разобраться, для чего нужна директива «&НаКлиентеНаСервереБезКонтекста».

Действие 4. Выполнение обработки данных.

Когда предполагается выполнение одной и той же обработки данных из нескольких участков программного кода, разумно этот код поместить в самостоятельную процедуру или функцию. Остаётся только решить, под какой директивой её написать.

Та-дам!

Для копирования у нас есть ксерокс. Но куда его поставить? На сторону клиента или сервера? Под какой директивой его разместить?

Как было озвучено ранее – любая процедура и функция поддерживает обработку информации, переданной в неё в качестве параметров.

Давайте для начала попробуем разместить копировальный аппарат на стороне клиента. Для этого описываем процедуру или функцию «Ксерокс» под директивой «&НаКлиенте». Тогда процесс клиентской части в любой момент сможет без проблем обратиться к ней и все действия будут выполнены в соответствии с программным кодом.

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

Получается, что использовать директиву «&НаКлиенте» неправильно, а директиву «&НаСервере», как мы изучили ранее – нежелательно. Давайте посмотрим поведение системы при использовании директивы «&НаСервереБезКонтекста».

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

Избавиться от излишней передачи на сервер при сохранении возможности копирования на клиенте и на сервере можно при помощи директивы «&НаКлиентеНаСервереБезКонтекста».

Не углубляясь в детали, отметим, что метод, описанный под данной директивой управления, создаётся в двух копиях – и на стороне клиента, и на стороне сервера. Это позволяет выполнить необходимые действия там, где появилась потребность в них (клиент/сервер), без лишних серверных вызовов.

С точки зрения выполнения программы результат будет одинаков. Но объяснение «почему так не надо делать» – это уже совершенно другая тема…

Вместо заключения

В данной статье мы на наглядных примерах рассмотрели влияние различных директив компиляции на такое явление системы «1С:Предприятие 8», как серверный вызов. Как видно, основная причина для выбора правильной директивы – производительность транспортировки данных между клиентской и серверной частью.

Придерживайтесь при разработке следующих правил:

  • По возможности не передавайте контекст формы на сторону сервера
  • Минимизируйте количество текущих серверных вызовов
  • Длительные и ресурсоёмкие задачи запускайте на выполнение на стороне сервера (при возможности – в фоновом режиме).

Учитывайте потребность в доступности тех или иных видов данных, обоснованность передачи управления и не стесняйтесь при необходимости дробить процедуры и функции. И будет Вашему серверному вызову всегда легко, а Вы от пользователей Вашей программы получите «молчаливую благодарность»!

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

Пользователей, применяющих этот функционал, – 25 человек, и каждый из них за рабочий день в среднем совершает 110 таких операций. Всего впустую за рабочий месяц потрачено 28875 секунд (21 рабочий день * 25 человек * 110 операций * 0,5 секунды) = 8,02 часов.

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

Об авторе

Автор статьи – Павел Ванин

admin

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *