Клиент- серверные вызовы. Общие модули 1с модуль управляемого приложения

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

• Что такое программный модуль и из каких разделов он состоит?
• Для чего нужен модуль приложения? Почему их два? Когда какой запускается? Какие есть тонкости работы?
• Какие события связаны с началом работы системы, как и где их обрабатывать?
• Для чего нужен модуль внешнего соединения? Когда и как его использовать?
• Когда используется модуль сеанса?
• Что такое общие модули? Какие у него свойства и правила работы? Для чего нужно использовать свойство “Повторное использование возвращаемых значений”?
• Когда используется модуль формы и какие события в нем могут быть обработаны?
• Для чего предназначен модуль объекта? Из каких разделов он состоит? Как посмотреть доступные события модуля?
• Какие тонкости работы существуют с модулями менеджера значения (для констант) и модулями набора записей (для регистров)?
• В чем отличия между модулем объекта и модулем менеджера? Когда нужно использовать последний?

Применимость

В статье рассматривается платформа «1C:Предприятие» 8.3.4.496. Материал актуален и для текущих релизов платформы.

Модули в «1С:Предприятие 8.3»

Модули – это те объекты, где содержится программный код.

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

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

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

Внутри каждой процедуры можно обращаться к переменной модуля. Кроме того, внутри самой процедуры может быть еще одно объявление переменной с таким же именем. Это будет локальная переменная данной процедуры.

Несмотря на одинаковое название, это две разные переменные: одна используется внутри конкретной процедуры, а другая – вне ее.

В некоторых модулях для переменных может указываться место компиляции (доступность) на Сервере или на Клиенте. Например:

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

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

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

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

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

Модуль приложения

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

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

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

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

Модуль приложения не будет работать, если запуск программы 1С осуществляется, например, в режиме com-соединения. В этом случае окно программы не создается.

Следует отметить, что в Платформе 8.3 существует два разных модуля приложения: модуль Управляемого приложения и модуль Обычного приложения. События модуля управляемого приложения отрабатываются при запуске Тонкого и Толстого клиента Управляемого приложения и Веб-клиента.

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

Если приложение работает и в режиме Управляемого , и в режиме Обычного приложения , то необходимо описывать процедуры-обработчики как для модуля Управляемого приложения , так и для модуля Обычного приложения .

Модуль Управляемого приложения можно выбрать из контекстного меню корневого узла конфигурации.

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

Чтобы открыть модуль Обычного приложения , следует обратиться к настройкам конфигурации (команда Параметры в меню Сервис ).

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

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

Список событий, которые можно обрабатывать, для Управляемого и Обычного приложения одинаков.

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

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

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

Есть два события, связанные с началом работы системы (“перед” и “при”). Два события, связанные с завершением работы системы (“перед” и “при”). А также обработка внешнего события (например, события торгового оборудования).

Когда выполняется обработчик события “перед”, считается, что действие еще не совершено. Когда выполняется обработчик события “при” – действие уже совершено.

Событие ПередНачаломРаботыСистемы возникает в тот момент, когда производится запуск Предприятия 8.3, но само приложение еще не появилось на экране. У данного события есть такой параметр, как Отказ .

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

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

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

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

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

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

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

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

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

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

В этом модуле есть события: ПриНачалеРаботыСистемы и ПриЗавершенииРаботыСистемы .

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

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

В Модуле внешнего соединения возможно описывать экспортные переменные и экспортные методы, которые будут доступны на той стороне, где происходит внешний вызов 1С:Предприятие 8.3.

Поскольку во внешнем соединении нет пользовательского интерфейса, Модуль внешнего соединения компилируется целиком на Сервере.

Модуль сеанса

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

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

В Модуле сеанса предусмотрено событие УстановкаПараметровСеанса .

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

В Модуле сеанса описываются различные действия по инициализации параметров сеанса в зависимости от разных условий.

В данном модуле, как правило, описываются несколько процедур, которые вызываются из процедуры УстановкаПараметровСеанса . Поэтому все эти процедуры выделены в отдельный модуль.

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

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

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

• процедура УстановкаПараметровСеанса выполняется не только при старте системы, а также при обращении к неинициализированным параметрам сеанса. Т.е. обработчик УстановкаПараметровСеанса может вызываться неоднократно в процессе работы приложения;
• если количество элементов в массиве параметров сеанса равно нулю (у массива требуемых параметров тип данных Неопределено), то это момент запуска приложения;
• поскольку Модуль сеанса работает в привелигированном режиме и проверки прав доступа не будет, следует очень аккуратно работать с объектами базы данных, так как пользователь может получить доступ к тем данным, которые ему не должны быть предоставлены;
• при запуске системы достоверно еще не известно: будет ли запущено приложение. При этом в обработчике события УстановкаПараметровСеанса могут быть произведены лишние действия.

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

Логически связанные методы можно группировать в разные Общие модули. Эти модули создаются внутри ветки Общие.

Можно добавить любое количество общих модулей. Чтобы методы Общих модулей были доступны в других местах конфигурации, необходимо их определять с ключевым словом Экспорт. Клиентские процедуры общих модулей будут доступны на Клиенте, а серверные – на Сервере.

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

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

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

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

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

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

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

Кроме того, использование глобальных общих модулей влияет на понимание кода. Вызов методов не глобального общего модуля осуществляется через имя Общего модуля и имя метода, например:
МодульРасчетаСебестоимости.РаспределитьКосвенныеЗатраты();

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

Для Общего модуля в Палитре свойств можно установить свойство Привилегированный .

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

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

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

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

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

Если Общий модуль является привилегированным, то процедуры этого модуля могут быть скомпилированы только на Сервере.

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

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

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

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

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

Кроме того, если перевести режим редактирования конфигурации в Управляемое приложение и обычное приложение, то будет возможен еще один контекст компиляции – Клиент (обычное приложение).

Таким образом, выделяется четыре варианта функционирования программы. В зависимости от запущенного приложения, в зависимости от работы на Клиенте или на Сервере будут доступны или недоступны определенные Общие модули.

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

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

При этом процедура не может быть доступна в контексте, который не доступен в целом для всего модуля.

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

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

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

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

При таком подходе в отдельных Общих модулях будут располагаться клиентские процедуры, и в отдельных Общих модулях – процедуры серверные.

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

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

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

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

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

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

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

Тем не менее, существуют определенные временные ограничения. Очистка кэша происходит автоматически через 20 минут после попадания значения в кэш.

Модуль формы

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

Кроме событий, связанных с элементами управления формы (кнопки, поля ввода) существуют события, связанные непосредственно с самой формой.

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

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

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

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

Список событий управляемой формы виден также в списке свойств непосредственно для самой формы. Данный список вызывается в редакторе управляемых форм.

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

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

Модуль объекта

Данные модули характерны для справочников, документов, планов видов расчетов, планов счетов и многих других объектов. Модуль объекта предназначен для обработки стандартных событий. Например, событие на ввод элемента справочника, событие на запись элемента, удаление, проведение документа и т.д.

В принципе, событие записи существует и в Модуле формы. Но событие записи в Модуле формы возникает в процессе интерактивной записи, при работе с конкретной формой.

Событие записи в Модуле объекта будет выполняться при любой записи из любой формы данного объекта. Кроме того, если объект записывается программно, в этом случае будет срабатывать событие модуля объекта.

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

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

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

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

В разделе основной программы можно, например, выполнять инициализацию локальных переменных данного модуля. Этот программный код будет выполняться при обращении к данному Модулю объекта.

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

Это связано с особенностями самих объектов. К таким объектам относятся Константы и Регистры . Для Констант не существует модуля объекта, но существует очень похожий модуль, который называется Модулем менеджера значения .

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

Весь контекст модуля исполняется на Сервере.

Для регистров существует Модуль набора записей.

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

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

Т.е. помимо использования фиксированных методов класса объектов можно создавать для объекта дополнительные методы в Модуле объекта. В данном модуле следует описать соответствующую процедуру с ключевым словом Экспорт .

Тогда будет возможно обращаться к этой процедуре из вне. Причем данный метод будет отображаться в контекстной подсказке. Новые методы в контекстной подсказке выделяются синим шрифтом (синий значок p() для процедур и f() для функций).

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

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

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

Модуль менеджера

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

В Модуле менеджера можно переопределить некоторые стандартные события.Например, в ОбработкеПолученияДанныхВыбора , когда выбирается элемент из справочника, можно сделать какую-то дополнительную фильтрацию или проверку.

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

Для того, чтобы выполнить данное обращение, необходимо получить тип данных СправочникМенеджер .

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

После этого будут доступны экспортные переменные и методы Модуля объекта. Для Модуля менеджера обращение более простое, например:
Справочники.Контрагенты.ИмяМетода

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

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

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

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

Кроме того, обращение к Модулю объекта – это все-таки более длительное действие. Поэтому решать данную задачу в модуле менеджера более предпочтительно.

На этом завершим наше знакомство с модулями в конфигурации системы «1С:Предприятие». Если подвести краткое резюме всему вышенаписанному, то в сухом остатке получаются следующие выводы:

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

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

Пока весь наш программный код мы рассматривали отрывочно от прикладного решения, и как правило, писали его в какой-то своей небольшой тестовой конфигурации. А вы в курсе, что «нельзя просто так взять» и начать редактировать код типовой конфигурации? Нет? Тогда в следующей статье мы все это объясним!

Модули платформы 1С:Предприятие 8.3, 8.2

Общие модули

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

В таких модулях отсутствует раздел переменных.

Выполнение общих модулей зависит от выставленных параметров в их свойствах:

Флаг "Глобальный"

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

Флаг "Сервер"

Функции такого модуля могут выполняться на сервере.

Флаг "Клиент (обычное приложение)"

Функции такого модуля могут выполняться на клиенте в режиме обычного приложения.

Флаг "Клиент (управляемое приложение)"

Функции такого модуля могут выполняться на клиенте в режиме управляемого приложения.

Флаг "Вызов сервера"

Флаг доступен для модулей с установленным флагом "Сервер". Разрешает вызов на клиенте экспортных функций этого модуля (которые будут выполняться на сервере).

Флаг "Внешнее соединение"

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

Флаг "Привилегированный"

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

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

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

Модуль приложения

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

Не следует его перегружать, так как это влияет на время запуска приложения.

Модуль сеанса

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

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

С уважением, (преподаватель и разработчик ).

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

Обычно программный модуль состоит из трех разделов:

• область объявления переменных ;
• область описания процедур и функций ;
• основной текст программы .

Пример структуры программного модуля:

//***************** ОБЛАСТЬ ОБЪЯВЛЕНИЯ ПЕРЕМЕННЫХ **********************

Перем Фамилия Экспорт; //это глобальная переменная
Перем Имя , Отчество ; //это переменная модуля
Перем ФИО ; //это тоже переменная модуля и к ней можно обращаться

//из любой процедуры и функции нашего модуля

//*************** ОБЛАСТЬ ОПИСАНИЯ ПРОЦЕДУР И ФУНКЦИЙ ****************

Процедура Процедура1 ()
Перем Итог ; //Итог это локальная переменная (переменная процедуры)

Итог = Фамилия + " "+ Имя + " "+ Отчество ;

КонецПроцедуры

Функция Функция1 ()

// операторы функции

Возврат(Фамилия + " "+ Имя );

КонецФункции

//******************* ОСНОВНОЙ ТЕКСТ ПРОГРАММЫ ***********************

Фамилия = "Иванов";
Имя = "Иван";
Отчество = "Иванович";

//******************************************************************************

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

Область описания процедур и функций размещается от первого оператора Процедура или оператора Функция до любого исполняемого оператора вне тела описания процедур или функций.

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

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

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

Контекст выполнения модулей делится на клиентский и серверный. Кроме того, некоторые программные модули могут быть скомпилированы как на стороне клиента, так и на стороне сервера.

Модуль приложения (управляемого или обычного)

В модуле приложения описываются процедуры (обработчики) событий, которые инициализируются при старте и окончании работы системы. Например, при начале работы приложения можно обновить какие-либо данные конфигурации, а при завершении работы - поинтересоваться, стоит ли вообще выходить из программы. Кроме того, в данном модуле перехватываются события от внешнего оборудования, например, торгового или фискального. Стоит отметить, что модуль приложения выполняется только в случае интерактивного запуска приложения, то есть когда запускается окно программы. Этого не происходит, если приложение запускается в режиме com- соединения.
В платформе 1С 8 существует два различных модуля приложения. Это модуль Обычного приложения и модуль Управляемого приложения. Они срабатывают при запуске различных клиентов. Так, модуль Управляемого приложения срабатывает при запуске веб-клиента, тонкого клиента и толстого клиента в режиме управляемого приложения. А модуль обычного приложения срабатывает при запуске толстого клиента в режиме обычного приложения. Настройка режима запуска приложения задается в свойстве конфигурации "Основной режим запуска".

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

Как уже отмечалось выше, модуль приложения обрабатывает события запуска и завершения приложения. Для обработки каждого из этих событий в модуле приложения существует пара обработчиков Перед… и При… Отличия между заключается в следующем: при выполнении кода в обработчике Перед… действие еще не свершилось и мы можем отказаться от его выполнения. Для этого предназначен параметр Отказ. В обработчиках При.. действие уже свершилось, и отказаться от запуска приложения или выхода из него мы не можем.

Модуль внешнего соединения

• может содержать все 3 области
• располагается в корневом разделе конфигурации

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

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

Модуль сеанса

• выполняется на стороне сервера
• располагается в корневом разделе конфигурации

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

В модуле сеанса существует одно единственное событие «УстановкаПараметровСеанса», которое выполняется самым первым, даже раньше события модуля приложения ПередНачаломРаботыСистемы. В нем не доступны раздел объявления переменных и раздел основной программы. А так же нельзя объявлять экспортные методы. Модуль компилируется на стороне сервера.

Общие модули

• может содержать область описания процедур и функций
• выполняется на стороне сервера или клиента (зависит от настроек модуля)
• располагается в ветке дерева объектов конфигурации «Общие» - «Общие модули»

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

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

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

Модуль формы

• может содержать все 3 области
• выполняется на стороне сервера и клиента

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

Структура управляемой формы содержит раздел объявления переменных, описания процедур и функций и основной текст программы (выполняется в момент инициализации формы). К стандартным событиям формы можем обратиться через список ожидаемых процедур и функций формы (Ctrl+Alt+P) , либо через палитру свойств самой формы.

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

Модуль объекта

• может содержать все 3 области
• выполняется на стороне сервера

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

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

Модуль менеджера объекта

• может содержать все 3 области
• выполняется на стороне сервера

Модуль менеджера объектов появился только начиная с версии 1С 8.2. Модуль менеджера существует у всех прикладных объектов и предназначен для управления этим объектом как объектом конфигурации. Модуль менеджера позволяет расширить функциональность объекта за счет введения (написания) процедур и функций, которые относятся не к конкретному экземпляру объекта базы данных, а к самому объекту конфигурации. Модуль менеджера объектов позволяет размещать общие процедуры и функции для данного объекта и обращаться к ним из вне, например, из обработки (конечно, если эта процедура или функция будет с ключевым словом Экспорт). Что это нам дает нового? В общем-то, ничего, кроме упорядочивания процедур по объектам и хранения их в отдельных местах - Модулях менеджеров объектов. Мы можем с таким же успехом эти процедуры и функции помещать в общих модулях, но 1С советует общие процедуры и функции объектов размещать в Модуле менеджера объектов. Примеры использования процедур и функций Модуля менеджеров объектов: первоначальное заполнение отдельных реквизитов справочника или документа по определенным условиям, проверка заполнения реквизитов справочника или документа по определенным условиям и т.д.

Модуль команды

• может содержать раздел описания процедур и функций
• выполняется на стороне клиента

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также: Ограничение на установку признака «Вызов сервера» у общих модулей

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

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

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

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

См. также: минимизация кода, выполняемого на клиенте

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

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

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

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

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

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

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

В платформе 8.2 в управляемом приложении для оптимизации работы приложений предлагается разделение функции клиента и сервера. На клиенте, например, нельзя обращаться к данным БД. А на стороне сервера не доступны данные формы, в модуле которой находится процедура с директивой &НаСервереБезКонтекста. Программный код в 1С располагается в различных модулях, модуле объекта, модуле формы, общих модулях и т.д. Процедуры и функции каждого модуля могут компилироваться как на сервере, так и на клиенте. Рассмотрим возможности вызова различных процедур и функции из процедур, компилируемых на стороне сервера, и процедур, компилируемых на стороне клиента.

Итак, со стороны клиента можно вызывать

1) клиентские процедуры данного модуля, с директивой &НаКлиенте;

2) серверные процедуры данного модуля, с директивой &НаСервере;

3) клиентские процедуры общего модуля, с директивой &НаКлиенте(при условии наличия в свойствах доступности в нескольких контекстах, «Клиент» обязателен и др.);

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

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

Со стороны сервера можно вызывать

1) серверные процедуры данного модуля, с директивой компиляции &НаСервере;

2) все процедуры серверного общего модуля, причем в свойствах общего модуля должно быть только свойство «Сервер». Директиву &НаСервере в общем модуле в этом случае не пишут;

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

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

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

Существуют рекомендации использовать общие модули, скомпилированные только на сервере или только на клиенте. Соответственно использовать в модуле со свойством «Клиент» все клиентские модули, а в модуле со свойством «сервер» использовать все серверные методы.

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

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