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

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

Я цепляюсь из программы (на c#) через COM к 1с (серверная, не файловая). Подключение проходит успешно, но я не могу обратиться к функции общего модуля.
Пишет следующее:
«2016-05-30 16:19:13.1634 ERROR Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: «System.__ComObject» не содержит определения для «ОбщийМодуль»
в CallSite.Target(Closure , CallSite , ComObject )
в CallSite.Target(Closure , CallSite , Object ). «

на c# код следующий:

string connectionString = «srvr='» + mainConfig.base1cServer +
«‘;ref='» + mainConfig.base1cName +
«‘;Usr='» + mainConfig.base1cUser +
«‘;Pwd='» + mainConfig.base1cPassword + «‘;»;
V83.COMConnector com1c83 = new V83.COMConnector();
com1c83.PoolCapacity = 10;
com1c83.PoolTimeout = 60;
com1c83.MaxConnections = 2;
connection1C = com1c83.Connect(connectionString);
dynamic result1c = connection1C.ОбщийМодуль.Тест(new object[] <>);

в 1С код следующий:

Функция Тест() Экспорт
Возврат «тест»;
КонецФункции

Всё это находится в модуле «ОбщийМодуль» (созданный мной) в разделе «Общие модули». У этого модуля активированы следующие параметры:
-Сервер
-Внешнее соединение
-Вызов сервера

В случае с файловой базой — всё работает.
В случае с серверной базой пишет ошибку, указанную в начале поста.

Я пробовал делать общий модуль Глобальным, и тогда в c# команда выглядит так:
dynamic result1c = connection1C.Тест(new object[] <>);
С файловой это работает, с серверной нет.

Я также пытался написать тот же метод в «Модуль внешнего соединения» в 1с-ке. И опять, с файловой это работает, а с серверной — нет.

Подскажите, в чём прикол серверной версии 1с? И как мне обратиться к методу модуля?

Вызов функции из общего модуля

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

По теме из базы знаний

• Замена вызовов методов общих модулей во внешних обработках/отчетах
• Обработка «Вызовы общих модулей» (8.2)
• Поиск неиспользуемых экспортных методов (процедур и функций) общих модулей
• Работа с SQL. Шаблон общего модуля
• Если хочется функционального программирования с функциями высшего порядка и map, filter, reduce

Найденные решения

2. alex-l19041 8 12.04.19 17:26 Сейчас в теме

(1) из &НаКлиенте вызываете &НаСервере
а затем ПроизвольныйМодуль.Произвольная()

memb3r; oleg-x; + 2 – Ответить

Остальные ответы

• Дата
• Дата
• Рейтинг всех уровней
• Рейтинг 1-го уровня
• Древо развёрнутое
• Древо свернутое

Свернуть все

2. alex-l19041 8 12.04.19 17:26 Сейчас в теме

(1) из &НаКлиенте вызываете &НаСервере
а затем ПроизвольныйМодуль.Произвольная()

memb3r; oleg-x; + 2 – Ответить

3. user1200515 12.04.19 17:33 Сейчас в теме

(2)Сделала так, все работает, спасибо)
&НаКлиенте
Процедура ПриОткрытии()
Промежуточная()
КонецПроцедуры

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

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

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

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

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

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

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

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

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

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

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

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

• Сервер (флажок Вызов сервера установлен)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

• Тексты модулей
• Структура модуля

Общие модули в 1С 8.3

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

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

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

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

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

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

 Процедура АлгоритмСерверКлиент() Экспорт #Если ТонкийКлиент Тогда // код выполняется, если вызов процедуры пришел с клиента ПоказатьОповещениеПользователя("На клиенте"); ИначеЕсли Сервер Тогда // код выполняется, если вызов процедуры пришел с сервера ПеременнаяСервер = "Серверный вызов"; #КонецЕсли КонецПроцедуры 

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

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

 &НаКлиенте Процедура ТоварыЦенаПриИзменении(Элемент) ПересчетСуммы(); КонецПроцедуры &НаКлиенте Процедура ТоварыКоличествоПриИзменении(Элемент) ПересчетСуммы(); КонецПроцедуры &НаКлиенте Процедура ПересчетСуммы() СтрокаТЧ = Элементы.Товары.ТекущиеДанные; СтрокаТЧ.Сумма = СтрокаТЧ.Количество * СтрокаТЧ.Цена; КонецПроцедуры 

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

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

 Процедура РассчитатьСтроку(СтрокаТабличнойЧасти) Экспорт СтрокаТабличнойЧасти.Сумма = СтрокаТабличнойЧасти.Количество * СтрокаТабличнойЧасти.Цена; КонецПроцедуры 

 &НаКлиенте Процедура ТоварыЦенаПриИзменении(Элемент) //вызов процедуры из общего модуля РасчетыВСистеме.РассчитатьСтроку(Элементы.Товары.ТекущиеДанные); //ПересчетСуммы(); КонецПроцедуры &НаКлиенте Процедура ТоварыКоличествоПриИзменении(Элемент) //вызов процедуры из общего модуля РасчетыВСистеме.РассчитатьСтроку(Элементы.Товары.ТекущиеДанные); //ПересчетСуммы(); КонецПроцедуры &НаКлиенте Процедура ПересчетСуммы() СтрокаТЧ = Элементы.Товары.ТекущиеДанные; СтрокаТЧ.Сумма = СтрокаТЧ.Количество * СтрокаТЧ.Цена; КонецПроцедуры 

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

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

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

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