М. Г. Радченко, Е. Ю. Хрусталева

Инструменты для создания тиражируемых приложений «1С:Предприятия 8»

М. Г. Радченко, Е. Ю. Хрусталева

Инструменты для создания тиражируемых приложений «1С:Предприятия 8»

Электронная книга в формате ePub; ISBN 978-5-9677-3423-6.

Версия издания от 10.04.2024.

Электронный аналог издания "Инструменты для создания тиражируемых приложений «1С:Предприятия 8»"
(ISBN978-5-9677-1554-9, М.: ООО "1С-Паблишинг", 2011; артикул печатной книги по прайс-листу фирмы "1С": 4601546090706; по вопросам приобретения печатных изданий издательства "1С-Паблишинг" обращайтесь к партнеру "1С", обслуживающему вашу организацию, или к другим партнерам фирмы "1С".)

---

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

© ООО «1С-Паблишинг», 2024
© Оформление. ООО «1С-Паблишинг», 2024

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

---

Фирма "1С"
123056, Москва, а/я 64, Селезневская ул., 21.
Тел.: (495) 737-92-57.
1c@1c.ru, http://www.1c.ru/
Издательство ООО "1С-Паблишинг"
127434, Москва, Дмитровское ш., д. 9.
Тел.: (495) 681-02-21.
publishing@1c.ru, http://books.1c.ru/

Введение

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

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

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

При подготовке материала были использованы различные источники информации:

• опыт преподавания на учебных курсах по платформе и прикладным решениям «1С:Предприятия 8»;
• опыт внедрения прикладных решений;
• опыт, накопленный разработчиками фирмы «1С»;
• материалы информационно-технологической поддержки (ИТС);
• материалы форума партнеров-разработчиков на сайте http://partners.v8.1c.ru;
• общение на партнерских семинарах, проводимых фирмой «1С».

Глава 1. Поставка прикладных решений

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

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

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

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

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

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

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

Рис. 1.1. Схема взаимодействия разработчика с пользователем

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

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

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

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

Это обновление разработчик записал на физический носитель, а также выложил на доступный всем пользователям его прикладного решения FTP- или HTTP-ресурс. Предположим, пользователю нужно срочно получить обновление своего прикладного решения, и он не может ждать, пока посылка с CD-ROM, содержащим обновление, дойдет к нему по почте. В этом случае пользователь, благодаря механизму поставки и поддержки, может обратиться к указанному FTP- или HTTP-ресурсу и обновить свое прикладное решение прямо с этого ресурса. Причем если пользователь не вносил никаких изменений в прикладное решение, обновление до версии 2 будет выполнено полностью автоматически. Если же изменения вносились, то механизм поставки и поддержки попросит пользователя указать, как поступить с теми объектами конфигурации, которые были изменены одновременно, как разработчиком, так и пользователем.

Механизм поставки и поддержки прикладных решений

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

Таблица 1.1. Варианты действий разработчика и пользователя

Разработчик	Пользователь
Не изменял	Не изменял
Не изменял	Изменил
Изменил	Не изменял
Изменил	Изменил

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

Таблица 1.2. Принятие решения о выполнении действий

Разработчик	Пользователь	Действие
Не изменял	Не изменял	Не изменять
Не изменял	Изменил	Не изменять
Изменил	Не изменял	Принять изменения разработчика
Изменил	Изменил	?

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

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

Правила поставки задает разработчик, а пользователь действует в соответствии с правилами поддержки и может изменять их (рис. 1.2).

Рис. 1.2. Правила поставки и правила поддержки

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

Существует четыре правила поставки:

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

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

• полная поддержка,
• поддержка с возможностью изменения.

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

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

Существует три правила поддержки:

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

По умолчанию правила поддержки устанавливаются следующим образом. Если разработчик установил правило поставки Изменения запрещены, то пользователю будет установлено правило поддержки Объект поставщика не редактируется (рис. 1.3).

Рис. 1.3. Установка правила поддержки

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

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

Рис. 1.4. Установка правил поддержки

В дальнейшем пользователь сможет изменить при необходимости правило поддержки.

Изменение режима поддержки

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

Начальный режим поддержки

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

Также можно установить в качестве начального режим поддержки с возможностью изменения. Для этого нужно выполнить сравнение/объединение конфигурации с файлом поставки. Файл поставки представляет собой специальным образом подготовленный файл конфигурации, о котором подробнее рассказывается в главе «Файл поставки» (рис. 1.5).

Рис. 1.5. Установка различных режимов поддержки конфигурации

Полная поддержка – поддержка с возможностью изменения

При желании пользователь может изменить режим поддержки конфигурации и включить возможность изменений. Для этого следует выполнить команду Конфигурация 4 Поддержка 4 Настройка поддержки… и в открывшемся окне настройки поддержки нажать кнопку Включить возможность изменения (рис. 1.6).

Рис. 1.6. Включение возможности изменения конфигурации

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

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

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

Поддержка с возможностью изменения – полная поддержка

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

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