Публикации. Расширения конфигурации Порядок разработки и использования

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

Изменение исходного кода

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

Плагины

Более безопасная в этом плане стратегия – плагины. Исходное приложение предоставляет плагину фиксированный набор интерфейсов, а также возможность зарегистрировать себя в приложении. При выходе новой версии приложения плагины, написанные для предыдущей версии, продолжат работать и в новой версии (при условии неизменности интерфейсов). Поведение плагинов в новой версии может отличаться от поведения в предыдущей, если поставщик ПО изменил поведение приложения. Концепция плагинов используется в самых разнообразных классах ПО – офисном и бизнес-софте, средах разработки (Visual Studio, Eclipse, …), графических и звуковых редакторах и т.п.

Подписки

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

Одна из разновидностей такого подхода – встраивание в основную программу возможности выполнять пользовательские скрипты на языках типа Visual Basic for Application (VBA). Кастомный код может, в частности, выполняться в ответ на события приложения. Тот же VBA показал себя очень мощным и гибким средством кастомизации; он встроен в Microsoft Office, AutoCAD, SolidWorks, CorelDRAW, WordPerfect, ESRI ArcGIS и другие продукты.

Кастомизации в решениях «1С»: начало

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

Изменение исходного кода приложений 1С

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

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

Исходные коды и метаданные прикладного решения «1С» (конфигурации) хранятся в базе данных, в той же самой, в которой лежат данные самого приложения (проводки, данные справочников и документов и т.п.), т.е. программа хранится вместе с данными. База данных с конфигурацией (и данными приложения) в терминологии 1С называется информационной базой (сокращенно – инфобазой).

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

Настройка поставки на стороне поставщика

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

Настройка поддержки на стороне клиента

Когда клиент начинает что-то менять в типовой конфигурации, в инфобазе создаются две конфигурации:

  1. Оригинальная конфигурация поставщика.
  2. Текущая конфигурация, измененная на стороне клиента.
И вот поставщик выпускает новую версию. Она может поставляться в виде полного приложения, а может - в виде пакета обновления с измененными объектами. При переходе на новую версию у нас на стороне клиента имеется 3 конфигурации, на основании которых осуществляется так называемое трехстороннее слияние конфигураций:
  1. Старая конфигурация от поставщика.
  2. Текущая конфигурация клиента (старая конфигурация от поставщика плюс изменения, сделанные в ней клиентом).
  3. Новая конфигурация от поставщика.
Понятно, что в ряде случаев объекты, измененные поставщиком, можно обновлять автоматически:
  • Объекты, не измененные клиентом.
  • Простые изменения объектов на стороне клиента (например, добавление дополнительных реквизитов к объекту).
В случае же, когда объект был изменен и на стороне клиента, и в новой версии от поставщика, необходимо ручное вмешательство. У нас есть мощный механизм сравнения и объединения не только для модулей кода, но и для моделей (метаданных, форм, отчетов…), но даже с этим механизмом объединение конфигураций может быть нетривиальной задачей.

Внешние отчеты и обработки

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

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

Кастомизации в облаках

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

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

Расширения конфигурации

Итак, нам нужно было придумать механизм кастомизации, который бы удовлетворял следующим требованиям:
  1. Позволял бы легко обновлять кастомизированное решение на новую версию, избегая ручной работы по объединению конфигураций.
  2. Позволял включать кастомизацию при определенных условиях (например, если мы работаем в контексте определенной организации).
  3. Снижал вероятность потери работоспособности кастомизации при переходе на новую версию исходной конфигурации.
  4. Имел возможность отключения кастомизации в случае проблем для сохранения работоспособности приложения.
Такой механизм, помимо применения в облачных решениях, сильно облегчил бы жизнь при переходе на новую версию на внедрениях типовых конфигураций, где необходимы кастомизации.
Мы придумали такой механизм и назвали его расширения . Этот механизм в каком-то смысле совмещает в себе два подхода к кастомизации – идеологию плагинов и механизм подписок.

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

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

Основная конфигурация и расширение с заимствованным документом СчетФактураВыданный

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

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

&После("ПередЗаписью") Процедура РасшАндромеда_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения) Если (ЭтотОбъект.Ответственный = Справочники.Пользователи.ПустаяСсылка()) Тогда ЭтотОбъект.Ответственный = МодульПользователи.ПолучитьТекущегоПользователя(); КонецЕсли; КонецПроцедуры
В новой версии конфигурации реализация записи документа может измениться, но наш код в расширении будет по-прежнему выполняться перед стандартным кодом записи документа и делать свою работу.

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

Порядок выполнения расширений

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

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

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

Кастомизация форм в расширениях

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

На форму можно добавить новую кнопку (или даже несколько). В случае если несколько расширений добавляют на одну и ту же форму свои кнопки – все они будут присутствовать на итоговой форме во время исполнения.

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

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

Преимущества расширений

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

Простота перехода на новую версию конфигурации

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

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

Изменения лежат отдельно

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

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

При этом есть способ понять, какие заимствованные объекты в конфигурации действительно изменены, а какие позаимствованы в режиме read-only – например, для использования в отчетах. В дереве объектов расширения есть кнопка фильтра «Изменённые и добавленные в расширении», после нажатия которой в дереве остаются только заимствованные объекты, модифицированные в этом расширении, и новые объекты, созданные в этом расширении.

Раннее оповещение об ошибках

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

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

Что дальше?

Мы считаем развитие расширений одним из главных направлений развития средств кастомизации в платформе «1С:Предприятие». Расширения, задуманные изначально для облегчения кастомизаций в облачном сервисе, были спроектированы так, чтобы облегчить и ситуации с кастомизациями и на не-облачных внедрениях.

Пока в расширениях можно откастомизировать не всё, что хочется. Например, пока нельзя создавать новые прикладные объекты (справочники, документы и т.д.) и нельзя добавлять новые реквизиты к существующим прикладным объектам. Мы работаем над этим (и над другими возможностями тоже) и практически в каждой новой версии платформы «1С:Предприятие» добавляем в расширения новые возможности: Добавить метки

Начиная с редакции 8.3.6 платформы 1С:Предприятия в ней появился механизм расширения конфигураций .

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

Новые возможности

Ограничения

Конечно есть и ограничения:

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

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

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

И в нем простейшая процедура, которая выводит сообщение:

Процедура ВывестиСообщение() Экспорт Сообщение = Новый СообщениеПользователю; Сообщение. Текст = "Это основная конфигурация" ; Сообщение. Сообщить() ; КонецПроцедуры

А теперь давайте выведем другое сообщение с помощью расширения. В первую очередь нам конечно же надо создать само расширение. В меню конфигуратора выбираем Конфигурация — Расширение конфигурации


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

Далее в списке расширений убираем флажки «Безопасный режим, имя профиля безопасности» и «Защита от опасных действий» :


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

Для этого в дереве метаданных основной конфигурации щелкаем правой кнопкой по нужному общему модулю и выбираем пункт «Добавить в расширение» :


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

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

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

&Вместо("ВывестиСообщение") Процедура Сообщения_ВывестиСообщение() // Вставить содержимое метода. ПродолжитьВызов() ; КонецПроцедуры

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

&Вместо("ВывестиСообщение") Процедура Сообщения_ВывестиСообщение_() Сообщение = Новый СообщениеПользователю; Сообщение. Текст = "Это расширение" ; Сообщение. Сообщить() ; КонецПроцедуры

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

Professia1c_ry_Расширения. ВывестиСообщение() ;

Оказалась вполне актуальной:)

Ok, давайте сделаем и эти выходные полезными.

Итак, сегодня еще одна тема “прикладной эксплуатации 1C”:

Механизм расширений в платформе 8.3.6

О чем речь?

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

При использовании расширений доработка конфигурации осуществляется в новой сущности – расширении конфигурации:

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

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

Чтобы Вы могли разобраться с этим более подробно, публикуем еще несколько видео + PDF по расширениям.

Итак, поехали:

Назначение расширений конфигурации

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

Объекты, которые можно изменять в расширении

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

Работа с расширениями в конфигураторе

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

Заимствование объектов

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

Создание собственных объектов в расширении конфигурации

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

Работа с расширениями в пользовательском режиме

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

Работа с управляемыми формами в расширениях конфигурации

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

Модуль управляемой формы и обработчики событий в расширениях конфигурации

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

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

Изучив опыт использования предыдущих версий программы, и учтя тот факт, что каким бы универсальным и всеобъемлющим не было конкретное решение, в конечном итоге в 90% случаев требуется его доработка под конечного пользователя. Разработчики 8 версии программы 1С реализовали несколько принципиально новых решений для минимизации необходимости изменения стандартных механизмов конфигураций:

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

Что такое расширения конфигурации 1С, как с ними работать, ограничения в использовании – вот тот спектр вопросов, которые мы попытаемся раскрыть в нашей статье.

Немного теории

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

  1. Сравнивать типовую и имеющуюся структуру метаданных;
  2. В случае существенного отличия типовых элементов следить за корректным обновлением;
  3. Вносить соответствующие изменения после обновления.

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

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

Ситуации, в которых можно использовать расширения

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

  • Расширения могут работать с управляемыми формами;
  • Механизм поддерживает изменение и добавление существующих подсистем;
  • До выхода платформы 8.3.8 в расширении можно было только изменять существующие роли, после обновления они позволили добавлять новые, ограничивая доступ даже к объектам основной базы;
  • Существующий механизм позволяет по собственному желанию изменять командный интерфейс подсистем и основного раздела конфигурации;
  • Также этот инструментарий позволяет добавлять обработки и отчеты без внесения изменений в структуру базы;
  • В версии платформы 8.3.9.718 значительно переработан механизм диагностирования совместимости расширения и основной конфигурации.

Из вышесказанного становится понятно, что:

  1. При работе с обычными формами функционал расширений значительно ограничен;
  2. Хотя и облегчился процесс обновления основной конфигурации, однако возможность использования конкретного расширения (в том числе и в качестве тиражных решений) может быть серьезно ограничена как изменениями исходной структуры, так и несколькими параллельно используемыми расширениями;
  3. Использовать этот механизм целесообразно в тех случаях, когда есть необходимость дифференциации внешнего вида и функционала, используемыми различными пользователями, либо когда собственными силами производится доработка типовой конфигурации, находящейся на поддержке.

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

Создание расширения

В конфигураторе войдем в меню Конфигурация->Расширения конфигурации, откроется форма (Рис.1).

Именно здесь и можно создать новое расширение. Нажмем кнопку «Добавить». Вот и окно нового расширения (Рис.2)

Рис.2

Рассмотрим его элементы:

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

Список поля «Назначение» состоит из трех значений, опишем их в порядке исполнения:

  1. Исправление – расширения этого назначения создаются для корректировки незначительных неточностей и ошибок в заимствованных объектах;
  2. Адаптация – значение по умолчанию, расширения этого типа предназначены для подстройки типовых объектов под требования конкретного пользователя, (если расширение создавалось в версии программы ниже 8.3.9, после обновления платформы оно будет иметь именно это назначение);
  3. Дополнение – вносят совершенно новый функционал в типовое решение.

Запуск расширения

Двойной щелчок на имени расширения в окне из Рис.1, открывает окно расширения (Рис.3)


Как видим, оно представляет собой дерево, подобное дереву основной конфигурации. И здесь возникает один вопрос, в каких случаях следует заимствовать объект?

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

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

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

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

Отработав и протестировав расширение на копии базы, его можно выгрузить в отдельный файл, для этого в окне (Рис.5) необходимо нажать кнопку «Конфигурация», выбрать пункт «Сохранить в файл». В отличие от обычных файлов конфигурации, имеющих расширение cf, файл дополнения к конфигурации будет иметь маску *.cfe.

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

Для подключения расширения в режиме 1С.Предприятие у пользователя должен быть включен режим «Все функции» и вход в программу должен быть осуществлен с правами Администратора.

Путь для подключения доработки выглядит следующим образом: Все функции->Стандартные->Управление расширениями конфигурации. Открывающееся окно представлено на Рис.6

Рис.6

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

Рис.7

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

Заимствование объектов и порядок срабатывания модулей

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

Рис.8

Добавим эту обработку в расширение.

Для этого:

  • Правой кнопкой мышки активизируем контекстное меню формы обработки (Рис.9);

Рис.9

  • Выберем пункт «Добавить в расширение»;
  • В дереве дополнительной конфигурации появится и сама обработка и дубликат её формы;
  • Открыв форму, мы обнаруживаем, что команда, вызывающая сообщение тоже есть, только ей не присвоен обработчик;
  • Добавление действия команды вызывает диалоговое окно (Рис.10) в котором помимо основных директив места исполнения команды, присутствуют еще группа «Тип вызова».

Рис.10

Мы имеем три типа вызова для имеющейся процедуры;

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

Оставим тип вызова в положении «Вызывать после» и добавим процедуру «Расш1_СообщитьПосле(Команда)» (Рис.11).

Рис.11

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

Рис.12

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

Механизм аннотаций

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

Рис.13

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

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

Кроме этого последовательность выполнения процедур добавляемых модулей можно регулировать с помощью аннотаций:

  • &Перед(«ИмяПроцедуры»);
  • &После(«ИмяПроцедуры»);
  • &Вместо(«ИмяПроцедуры»).

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

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

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

Для ликвидации такой «несправедливости» был создан метод ПродолжитьВызов().

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

Внесение изменений в модуль объекта

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

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

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

  • Выберем в конфигураторе «ПриемНаРаботу» и из его контекстного меню добавим его в наше расширение (кстати этот механизм имеет комбинацию горячих клавиш Альт+Шифт+Ф2);
  • После выбора соответствующего дополнения мы получим картинку, как на Рис.14;

Рис.14

  • Нас будет интересовать выделенный желтым цветом элемент «Модуль объекта», откроем его, активировав предварительно соответствующей галочкой (Рис.15);

Рис.15

  • Мы получим чистый лист программного модуля, обратим внимание на верхнюю панель, а точнее, на элемент, представленный на Рис.16, в ниспадающем списке здесь представлены события, которые можно обработать для данного объекта;

Рис.16

  • Попробуем в сообщении вывести номер документа при его записи, выбрав соответствующее событие;
  • Мы получим форму выбора типа вызова (Рис.17), определим, когда будет выводиться номер;

Рис.17

  • Код процедуры показан на Рис.18;

Рис.18

В некоторых случаях из-за установленной галочки «Безопасный режим», подключение расширения происходит с ошибкой.

Небольшой анонс

В ближайшее время фирма 1С планирует выпуск платформы 8.3.11, в которой они анонсировали возможность добавления собственных:

  • Документов;
  • Справочников;
  • Планов обмена;
  • Регистров сведений.

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

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

Предлагаем вашему вниманию новый механизм кастомизации приложений в облачном сервисе «1С:Предприятие через Интернет» (сайт): расширения конфигурации платформы «1С:Предприятие 8».

1. Зачем нужны расширения конфигурации

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

2. Возможности расширений конфигурации

С помощью расширений конфигураций вы можете:

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

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

3. Сравнение с дополнительными отчетами и обработками

Раньше функционал прикладных решений на базе платформы «1С:Предприятие 8» можно было расширять с помощью дополнительных отчетов и обработок. Этот механизм по-прежнему поддерживается (см. по ссылке), но расширения конфигурации использовать предпочтительнее:

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

4. Порядок разработки и использования

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

  1. Авторизация разработчиков. Право на добавление в сервис расширений конфигурации выдается фирмой «1С» сотрудникам обслуживающих организаций сервисасайт со статусом «1С:ЦСК» по их заявкам. Сотрудники этих организаций, получившие право на добавление в сервис расширений конфигурации, получают статус разработчик расширений конфигурации . Подробнее об этом см. в статье по ссылке .
  2. Разработка расширения. Разработчик расширений конфигурации разрабатывает расширение на своем компьютере, тестирует расширение. Требования к расширениям конфигурации приведены После того, как расширение конфигурации разработано и протестировано, разработчик добавляет его в сервис, как описано в статье по ссылке . Расширение помещается в централизованный каталог расширений сервиса.
  3. Аудит расширения. При добавлении в сервис расширения конфигурации или его новой версии расширение автоматически направляется на аудит . Аудит выполняется сотрудниками провайдера (администратора) сервиса.

  4. Публикация в сервисе. После успешного прохождения аудита расширение конфигурации получает статус «Опубликовано в сервисе» и может использоваться - то есть, встраиваться в приложения.
  5. Предоставление доступа клиентам (абонентам). Если правообладателем расширения конфигурации является обслуживающая организация, то она может:

    • использовать расширение в своих приложениях;
    • предоставить доступ к расширению своим клиентам (обслуживаемым абонентам) - одному, некоторым по своему выбору или всем (см. статью по ссылке).

    Если правообладателем расширения конфигурации является клиент (абонент), по заявке которого разработано расширение, то:

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

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

5. Сопровождение и обновление

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

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

6. Примеры расширений конфигурации

6.1. Пример 1: вывод сведений о погоде

Расширение конфигурации «Демо:Погода» (его можно скачать ) показывает, как в приложении можно вывести информацию, полученную из внешней системы посредством выполнения HTTP-запроса.

Расширение отображает в начальной странице приложения сведения о погоде, полученные через публичный API с погодного сайта http://api.wunderground.com .

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

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

  • http://api.wunderground.com - определение местоположения и получение сведений о погоде;
  • http://icons.wxug.com - получение картинки погоды.

Расширение совместимо с любой конфигурацией, так как не заимствует объектов из расширяемой конфигурации.

6.2. Пример 2: предоставление ленты новостей

Расширение конфигурации «Демо:RSS» (его можно скачать ) показывает, как приложение может предоставлять данные внешней системе - например, мобильному приложению.

Приложение создает внешний программный интерфейс для получения информации в формате RSS, используемом лентами новостей, о последних десяти поступлениях в кассу для конфигурации «Бухгалтерия предприятия, редакция 3.0». В составе расширения реализован XDTO-пакет (URI пространства имен http://www.w3.org/2005/Atom):

а также HTTP-сервис, возвращающий информацию о последних десяти поступлениях в кассу, полученную по данным документов «Приходный кассовый ордер».

Для удобства подключения к RSS-ленте расширение выводит в начальной странице приложения:

  • гиперссылку с адресом ленты новостей;
  • QR-код с адресом ленты новостей - для чтения с помощью камеры мобильного устройства.

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

Для генерации QR-кода расширение конфигурации обращается к внешнему ресурсу http://api.qrserver.com , поэтому это расширение также должно подключаться в небезопасном режиме.