1с как из клиентского общего модуля вызвать серверную функцию

Обновлено: 07.07.2024

Правила создания общих модулей

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:

Тип общего модуля Пример наименования Вызов сервера Сервер Внешнее соединение Клиент
(обычное приложение) Клиент
(управляемое приложение) 1. Серверный ОбщегоНазначения (или ОбщегоНазначенияСервер)

2. Серверный для вызова с клиента ОбщегоНазначенияВызовСервера 3. Клиентский ОбщегоНазначенияКлиент (или ОбщегоНазначенияГлобальный)

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

Сервер (флажок Вызов сервера снят),
Клиент (обычное приложение) ,
Внешнее соединение .

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

Серверные общие модули называются по общим правилам именования объектов метаданных.
Например: РаботаСФайлами , ОбщегоНазначения .

В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс "Сервер" (англ. "Server" ).
Например: РегламентныеЗаданияСервер , ОбменДаннымиСервер, ScheduledJobsServer .

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

Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом "ВызовСервера" (англ. "ServerCall" ).
Например: РаботаСФайламиВызовСервера, CommonServerCall .

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

2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность, определенную только для клиента) и имеют признаки:

Клиент (управляемое приложение) ,
Клиент (обычное приложение) .

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

Клиентские общие модули именуются с постфиксом "Клиент" (англ. "Client" ).
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиент, StandardSubsystemsClient .

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

Клиент (управляемое приложение) ,
Сервер (флажок Вызов сервера сброшен),
Клиент (обычное приложение) ,
Внешнее соединение .

Общие модули этого вида именуются с постфиксом "КлиентСервер" (англ. "ClientServer" ).
Например: РаботаСФайламиКлиентСервер , ОбщегоНазначенияКлиентСервер, UsersClientServer .

В то же время, как только возникает необходимость ветвить код в клиент-серверных общих модулях на серверный и клиентский, то не следует использовать для этого инструкции препроцессора. Вместо этого, функциональность, различную для клиента и для сервера, рекомендуется реализовывать по общим правилам в модулях соответствующего типа – см. пп. 2.1 и 2.3. Такое явное разделение клиентской и серверной бизнес-логики продиктовано соображениями повышения модульности прикладного решения, упрощения контроля со стороны разработчика над клиент-серверным взаимодействием и снижением риска ошибок из-за принципиальных отличий требований к разработке клиентского и серверного кода (необходимость минимизации кода, выполняемого на клиенте, разной доступностью объектов и типов платформы и др.). При этом нужно иметь в виду неизбежное увеличение числа общих модулей в конфигурации.

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

3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как "Процедуры", "Функции", "Обработчики", "Модуль", "Функциональность" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.

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

3.2. Дополнительно к общим модулям могут быть добавлены уточняющие постфиксы.

3.2.1. Для глобальных модулей добавляется постфикс "Глобальный" (англ. "Global" ), в этом случае постфикс "Клиент" добавлять не следует.
Например: РаботаСФайламиГлобальный, InfobaseUpdateGlobal .

3.2.2. Модули, выполняющиеся в привилегированном режиме, имеющие признак Привилегированный , именуются с постфиксом "ПолныеПрава" (англ. "FullAccess" ).
Например: РаботаСФайламиПолныеПрава .

3.2.3. Модули, предназначенные для реализации на сервере или на клиенте функций с повторным использованием возвращаемых значений (на время вызова или на время сеанса), именуются с постфиксом "ПовтИсп" (англ. "Cached" ) и "КлиентПовтИсп" (англ. "ClientCached" ) соответственно.
Например: РаботаСФайламиКлиентПовтИсп, UsersInternalCached .

3.2.4. Серверные и клиентские модули библиотечных конфигураций (которые предназначены не для самостоятельного использования, а для разработки других конфигураций) с процедурами и функциями, допускающие изменение своей реализации, именуются с постфиксами "Переопределяемый" (англ. "Overridable" ) и "КлиентПереопределяемый" (англ. "ClientOverridable" ).
Например: РаботаСФайламиКлиентПереопределяемый, CommonOverridable .

3.2.5. В локализуемых конфигурациях, на базе которых выпускаются национальные прикладные решения для различных стран или регионов, модули, реализующие национальную специфику, именуются с постфиксами "Локализация" (англ. "Localization" ) и "КлиентЛокализация" (англ. "Client Localization " ).
Например: ЭлктроннаяПодписьЛокализация, ElectonicSignature Localization .

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

Строка . СуммаСтроки = Строка . КоличествоСтроки * Строка . ЦенаСтроки ;

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

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

//обработчик вызываемый при изменении количества в строке табличной части

Вызов общего модуля

В свойствах общего модуля установим флаг Клиент:

В самом модуле добавим следующий код:

В модуле обработки вызовем оба метода общего модуля:

Переменные в общем модуле могут быть только внутри методов. Нельзя создать переменную, доступную во всем модуле или через свойства модуля.

Клиентский общий модуль

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

Серверный общий модуль

Если установлен только флаг Сервер, то к методам такого модуля можно будет обращаться только на сервер.

Вызов сервера

При установленных двух флагах Сервер и Вызов сервера к методам модуля можно обращаться как на клиенте, так и на сервере. Но само выполнение методов будет выполнено на сервере.

Клиент-серверный общий модуль

У такого общего модуля в свойствах нужно установить и флаг Клиент и флаг Сервер.

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

Вызывать серверные методы общего модуля можно только на сервере:

//чтобы вызвать серверный метод нужно перейти на сервер

Глобальный общий модуль

Если в свойствах модуля поставить флаг Глобальный, то для вызова методов общего модуля не нужно указывать имя общего модуля.

Глобальные общие модули будут скомпилированы при запуске конфигурации.

Привилегированный общий модуль

Общий модуль с таким флагом всегда выполняется без проверки прав доступа. Такой общий модуль может быть только серверным.

Повторное использование возвращаемых значений

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

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

Есть два варианта повторного использования возвращаемых значений:

Кешированный результат выполнения может быть удален в нескольких случаях:

Если в рабочем процессе сервера 1С не хватает оперативной памяти
Рабочий процесс был перезапущен
Клиент был переключен на другой рабочий процесс
Прошло 20 минут после сохранения или 6 минут после последнего использования
Если вызвать метод ОбновитьПовторноИспользуемыеЗначения

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

Для сохранения в кеше и повторного использования можно использовать параметры следующих типов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это процесс клиентской части приложения «1С:Предприятие 8». Он запускается на компьютере пользователя и сожительствует в оперативной памяти с другими процессами (38 вкладок браузера, поток аудио из социальной сети, telegram и другие). Может порождать серверный вызов.
Это процесс серверной части приложения «1С:Предприятие 8». Он существует на сервере 1С. Знает, какие клиентские сеансы в данный момент запущены, но самостоятельно не может инициировать взаимодействие с ними. Работает с клиентской частью только через полученный от неё серверный вызов. А это серверный вызов. Как было сказано выше, он порождается процессом клиентской части и призван «прислуживать» ему. Он передает запросы со стороны клиента на сторону сервера, а также занимается транспортировкой данных с клиента на сервер и обратно.

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

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

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

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

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

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

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

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

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

При таком построении программного кода происходит множественное обращение со стороны клиента на сервер – по количеству элементов цикла, запущенного на стороне клиента.

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

В данном случае количество серверных вызовов сведено к минимуму за счёт предварительной подготовки параметров.

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

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

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

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

Та-дам!

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

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

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

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

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

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

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

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

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

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

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

Так ли это важно думать об оптимизации? Тут имеет смысл вспомнить одну историю.

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

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

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

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

Создание общего модуля в 1С

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

Справа откроются свойства добавленного общего модуля, и нам предстоит разобраться, что обозначает каждое из них. Они могут быть различной направленности, поэтому, перед тем как настраивать новый объект, желательно определиться, что мы там будем хранить. Если что, в будущем можно будет изменить свойства в соответствии с задачами:

«Глобальный». Данный флаг ставится, если модуль предназначен для хранения процедур и функций, которые должны вызываться без указания имени модуля. Естественно, они должны быть экспортными, а их имена уникальными в разрезе всего глобального контекста. По использованию они не будут отличаться от стандартных функций платформы;
«Клиент». Зависит от настроек системы и регламентирует, могут ли процедуры модуля выполняться на стороне клиента;
«Сервер». Помечаются общие модули, в составе которых планируется помещать алгоритмы для выполнения на сервере;
«Внешнее соединение». Процедуры модуля с активацией этого свойства смогут выполняться через подключение внешнего источника;
«Вызов сервера». Отвечает за разрешения процедурам из модуля вызывать сервер, выполняясь на клиенте;
«Привилегированный». Активация этой настройки позволит при работе кода процедур модуля не проверять права доступа. Вызвать общий модуль с такой настройкой можно только на сервере. Настройки «Клиент» и «Внешнее соединение» будут сброшены;
«Повторное использование». Может принимать значения: «Не использовать», «На время сеанса», «На время вызова». При многократном вызове одной процедуры система может использовать рассчитанные ранее данные в рамках процедуры (вызов) или жизни всего сеанса (запуска 1С). Стоит быть очень осторожным с этой настройкой, так как из-за неправильного использования таких модулей могут возникать ошибки.

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

Пример переноса кода в общий модуль 1С

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

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

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

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

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

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

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

Читайте также: