Привет, меня зовут Сергей, разработчик 1С Programming Store
В статье рассмотрим роль и применение «Библиотеки стандартных подсистем» (БСП) в современной разработке на платформе 1С. Будут приведены примеры интеграции и подключения подсистем, а также советы по корректному использованию программного интерфейса БСП.
Содержание:
Что же такое «Библиотека стандартных процедур»?
Какие бывают типы подсистем в БСП
Что же такое «Библиотека стандартных процедур»?
Есть стандарты разработки 1С и библиотека стандартных подсистем. Эти две сущности идут рука об руку в современной среде разработки 1С. Можно посмотреть стандарт разработки #std551, где описано четкое определение:
Библиотека – это конфигурация, которая в отличие от «обычных» прикладных решений, не предназначена для использования конечными пользователями.
То есть когда мы скачиваем с сайта ИТС дистрибутив БСП и попробуем начать вести какой-то учет в этой конфигурации, то это будет, если не просто невозможно, то очень затруднительно. Просто потому что она для этого не предназначена.
Примеры, используемые в этой статье, будут выполняться в конфигурации, основанной на БСП, но уже с некоторыми добавленными объектами для демонстрации тех или иных возможностей БСП.
Еще в этом стандарте хочется обратить внимание на третий раздел, а именно на области видимости программного кода. Нередко бывают ситуации, когда разработчики начинают использовать тот программный код, который в принципе не предназначен для использования вне БСП. После этого у них при обновлении релиза библиотеки БСП появляются какие-либо проблемы. Часто это связано с тем, что бывает нарушение использования кода по областям видимости.
Выделяются три области видимости: первая – это программный интерфейс. Он содержит экспортные процедуры и функции, предназначенные для использования сторонними потребителями. То есть, с точки зрения Библиотеки БСП, это как раз мы – разработчики, использующие БСП для разработки. И такой программный интерфейс можно разделить на две категории:
-
Программный интерфейс для использования любыми внешними потребителями предназначен для вызова из произвольного места в коде конфигурации. Потребителями такого программного интерфейса чаще всего выступают расширения конфигурации, сторонние доработки конфигурации или другие программы.
-
Программный интерфейс для конкретных потребителей должен располагаться в определенном месте в коде конфигурации, определенном в документации, и может быть вызван только определенным потребителем. Такой программный интерфейс рекомендуется размещать в отдельном подразделе «Для вызова из других подсистем». Подробнее см. стандарт «Обеспечение обратной совместимости библиотек».
Ещё выделяем «Служебный программный интерфейс», обратите внимание, что в нём тоже могут быть размещены процедуры и функции. Программный код, размещенный в служебном программном интерфейсе, можно вызывать только из подсистем этой же библиотеки. То есть если я не разработчик БСП, то мне и не рекомендуется вызывать программный код, расположенный в «Служебных процедурах и функциях».
И третья область видимости – это «Служебные процедуры и функции». Тут также могут размещаться экспортные процедуры и функции. «Служебные процедуры и функции» предназначены для вызова из объектов этой же подсистемы.
Почему же стоит использовать «Библиотеку стандартных подсистем»? Потому что сама по себе БСП содержит достаточно большой объем программного кода, и весь этот программный код достаточно универсален. Например, если возникает необходимость рассылать отчеты, такая подсистема уже есть в БСП. Нужно более-менее гибко настроить управление доступом – такая подсистема тоже есть в БСП. Скорее всего, нет смысла изобретать велосипед, в ситуации когда его уже давно изобрели. Причем то, что изобрели, является конфигурацией. Соответственно, у нее есть поставка, которая обновляется и поддерживается. И всё это делается вендором. Не какой-то отдельной организацией, которая сегодня есть, а завтра нет, и ее код никто не поддерживает и не обновляет. Всё-таки это та же компания, которая выпускает платформу, и поэтому качество программного кода здесь высокое. В этом коде придерживаются стандартов разработки, и все процедуры и функции, которые предоставляет БСП, протестированы.
Также у «Библиотеки стандартных подсистем» есть хорошая документация, на которую я буду иногда ссылаться. И вообще умение разработчика пользоваться документацией БСП закрывает огромное количество вопросов возникающих при разработке программного кода, использующего БСП.
Также можно внедрять БСП не целиком, а частично. Но уверен, большинство разработчиков, читающих эту статью, все-таки работают с типовыми решениями, и нам не так часто нужно внедрять отдельные модули БСП. Нам нужно, скорее, интегрировать в собственные объекты отдельные элементы и подсистемы БСП.
Как установить БСП?
На сайте ИТС в разделе дистрибутивов есть возможность скачать дистрибутив, и в списке доступных дистрибутивов найти Стандартные подсистемы.
Можно выбрать последнюю версию. На сегодня это 3.1.10.545
Выбирая версию БСП, необходимо обращать внимание на версию технологической платформы, которая позволяет работать с этой версией БСП, и поэтому скачиваем «последнюю возможную» для имеющейся в нашем распоряжении платформы 1С:
Обратите внимание, что после установки скачанного дистрибутива БСП в каталоге установки есть папка «Инструменты разработчика», в которой расположены обработки, помогающие нам при работе с «Библиотекой стандартных подсистем». Это не стоит игнорировать. Тем более что разработчики БСП адаптировали их для удобного выполнения почти всех задач, возникающих при разработке.
Подробно останавливаться на процессе установки скачанного дистрибутива я не буду. Думаю, что в рамках статьи это излишне. Просто скачали, установили, создали тестовую базу, в которой и будем дальше работать.
Какие бывают типы подсистем в БСП
Всего существует два типа подсистем БСП: самостоятельные и интегрированные.
Самостоятельные подсистемы предоставляют готовый программный или пользовательский интерфейс. В случае если мы работаем с интегрированными подсистемами, то нам необходимо будет выполнить тесную интеграцию с нашими объектами. Например, если мы будем внедрять управление доступом, то нам нужно будет изменять определяемые типы, переопределяемые общие модули и так далее. О том, что конкретно нужно будет делать, чуть позже.
Соответственно, первые вопросы который возникают в начале работы с конфигурацией БСП: что можно использовать и какие объекты можно изменять?
Так, если мы откроем демонстрационную конфигурацию, то увидим достаточно большое количество объектов и можем сразу начинать программный интерфейс. Что можно использовать?
 |
 |
Например, мы решим найти справочник ИдентификаторыОбъектовМетаданных, подумав, что в модуле объекта этого справочника должен быть программный интерфейс, который возвращает нам идентификатор объекта метаданных по объекту метаданных. И мы найдем такую функцию. Называется ИдентификаторОбъектаМетаданных(), и она даже экспортная. То есть мы сможем её использовать.
Но обратите внимание: она располагается в области
#Область СлужебныеПроцедурыИФункции. И поэтому прямой вызов этой функции будет неправильным. Сам по себе справочник относится к подсистеме БазоваяФункциональность. И поэтому нужно вызывать ее из программного интерфейса именно этой подсистемы. Но, чтобы понять, где вообще располагается программный интерфейс, мы можем открыть из упомянутого выше каталога «Инструменты разработчика» обработку ГенерацияОписанияПрограммногоИнтерфейса.epf и посмотреть код, исполняемый по нажатии на кнопку Подготовить.
Что здесь происходит? Конфигурация выгружается
в XML:ВыгрузитьКонфигурациюВXML(); и после этого обходятся файлы, имеющие имя CommonModules, соответственно, это общие модули.
То есть программный интерфейс формируется именно по 
общим модулям. Значит нам не нужно искать программный интерфейс по всем объектам конфигурации. Просто идем в ту или иную подсистему и работаем с её программным интерфейсом. Кроме того, выше мы рассмотрели области видимости. Давайте обратим внимание на такой момент: у нас есть подсистема. Для примера возьмем любую. Например, СтандартныеПодсистемы – 
ЗапретРедактированияРеквизитовОбъектов. Если мы выберем объекты подсистемы, то мы увидим некоторый набор модулей которые есть у этой подсистемы. Поэтому мы должны искать не по всем объектам, а только по общим модулям, в которых либо нет постфикса, либо есть постфикс Клиент, либо есть постфикс КлиентСервер. Модуль должен выбираться в зависимости от того, в каком контексте мы находимся.
Если мы в серверном контексте, то вызываем серверный общий модуль ЗапретРедактированияРеквизитовОбъектов, если на клиенте, то вызываем ЗапретРедактированияРеквизитовОбъектовКлиент, если работаем с чем-то универсальным, что работает и на клиенте, и на сервере, то вызываем общий модуль с постфикстом КлиентСервер. В данном примере такого нет.
То есть, если я в работе буду использовать какие-либо процедуры или функции не из программного интерфейса, а непосредственно из модулей, то это чревато возникновением проблем при обновлении. Разработчики гарантируют обеспечение обратной совместимости библиотек только для программного интерфейса самих библиотек, а не других областей. Технически я, конечно, могу это сделать. Но нужно понимать, что эти методы способны очень сильно измениться: их расположение, наименование, набор параметров, они даже могут быть вообще удалены.
Как я говорил выше, у нас есть интегрированные и самостоятельные подсистемы. Что касается интегрированных подсистем, то мы как разработчики чаще всего будем пересекаться именно с ними. То есть что-то делать, дорабатывать и внедрять. У этих интегрированных подсистем есть определённый шаблон, как подключить подсистему к тому или иному объекту.
Для того чтобы выполнить подключение к объекту, обычно заключается некий «контракт». Давайте посмотрим это на примере того же ЗапретРедактированияРеквизитовОбъектов. Если мы собираемся что-то изменять, делать какие-то вставки программного кода, то нам необходимо найти модуль, который будет Переопределяемым. Т.е. все что мы будем менять в подсистеме, это переопределяемый общий модуль.
Открываем этот модуль. И там будет какой-нибудь метод, который по сути заключает некий контракт о том, что мы обязаны разместить некие вставки программного кода, что-то сделать с нашим объектом и так далее. То есть заключение контракта выполняется отдельным методом. В выбранном примере этот метод называется ПриОпределенииОбъектовСЗаблокированнымиРеквизитами(). Тут говорится о том, что Подсистема должна знать, что мы подключаем те или иные объекты к функционалу подсистемы, соответственно, перечисляя их удобным для подсистемы способом.
Способ всегда описан в комментарии. Вот так:
Конечно, желательно, кроме комментариев к методу, пользоваться и документацией.
И вот тут из списка добавленных демонстрационных объектов мы видим, что они как раз выполняют контракт. Если мы откроем первый из добавленных объектов, справочник _ДемоКассыККМ, то у него в модуле менеджера и увидим процедуру ПолучитьБлокируемыеРеквизитыОбъекта (), которая возвращает реквизиты, описанные в комментарии метода, определяющего контракт. Кроме того, в комментарии мы этого не видим, но в документации сказано, что необходимо вставить при создании на сервере некоторые части программного кода. Потому что нельзя никак изменить программный код в форме, не изменив саму форму. Идем в саму форму и реализуем выполнение этого контракта, который мы заключили. Соответственно, по результатам у нас будет работать блокирование реквизитов для справочника _ДемоКассыККМ.
Итак, первый прием – это использование переопределяемых общих модулей и вставок программного кода в наш объект. А второй прием, который используется, нужен для тех ситуаций, когда нет возможности, не сохраняя данные, реализовать какой-то функционал.
Посмотрим это на примере подсистемы УправлениеДоступом. Идем в конфигуратор и делаем отбор по объектам этой подсистемы.
И здесь мы сталкиваемся с тем, что есть огромное количество регистров сведений, и разработчикам этой подсистемы нужно каким-то образом сохранять те данные, с которыми они работают – с объектами платформы. В этом случае предыдущая методика была бы очень неудобной. Ну представьте себе: в каждый регистр вставляли свой тип или нужно было бы вставлять какие-то части программного кода… Это не очень удобно, и при обновлении версии подсистемы, возможно, бы изменялся и состав этих регистров, и нам бы приходилось заново все это делать. Чтобы уменьшить количество действий разработчиков, используется следующий подход.
Есть такие типы объектов, как Общие модули переопределяемые, Подписки на событие и Определяемые типы. Общие модули переопределяемые мы рассмотрели выше, а теперь обратим внимание на второй и третий тип переопределяемых объектов.
Здесь, как пример, мы можем посмотреть на определяемый тип, который называется ВладелецЗначенийКлючейДоступаДокумент.
И если мы захотим расширить Регистр сведений КлючиДоступаКОбъектам, то можно видеть, что в измерении объект как раз и есть ссылка на этот расширяемый тип, в который мы можем добавить наш объект.
К сожалению, не всегда получается ограничиться только одной подобной вставкой. Иногда нужны подписки на события, и они будут разные. Например, если мы записываем документ, то нужно будет выполнять подписку на события, которая называется ПроверитьДоступПередЗаписьюДокумента.
Количество функционала, который может быть подключен благодаря изменению типов, может варьироваться. Получается некоторая абстракция. Мы не задумываемся, что там внутри, но просто расширяем тип, а уже ответственность за все действия ложится на разработчиков Библиотеки.
Использование Библиотеки стандартных подсистем позволяет разработчикам 1С значительно ускорить процесс создания решений за счет готового универсального кода, поддерживаемого и обновляемого официальным вендором.
Вступайте в нашу телеграмм-группу Инфостарт
