Адаптация систем с сохранением обновляемости

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

Рассмотрим те принципы, которые помогут в решении описанной задачи, на примере внедрения «1С:ERP Управление предприятием 2».

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

1. Изменение кода
2. Изменение форм
3. Изменение макетов
4. Изменение ролей
5. Различные изменения объектов метаданных

Изменение кода

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

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

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

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

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

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

Или

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

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

• Дате внесения изменений
• Авторе изменений
• Номере задачи, в соответствии с которой изменения были внесены
• И т.п. информацию

А для формирования самих маркеров настраивают шаблоны текста.

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

Не следует допускать следующих явлений:

• Вкладывать один маркер изменений в другой
• Располагать маркеры изменений непосредственно друг за другом (в этом случае должен быть один общий маркер)
• Использовать маркеры изменений за пределами типовых модулей

Изменение форм

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

Если требуется модифицировать, скажем, форму документа «Заказ клиента», то изменяется именно типовая форма. Здесь можно пойти двумя путями:

1. Либо изменить непосредственно саму форму в конструкторе, добавив новые или изменив типовые элементы формы
2. Либо изменять форму программно в обработчике «ПриСозданииНаСервере»

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

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

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

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

Изменение макетов

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

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

Для отчетов на системе компоновки данных (СКД):

• Изменения запросов маркируются аналогично изменениям кода
• Изменения структуры СКД можно выполнить в пользовательском режиме за счет настройки варианта отчета, либо же программно

Изменение ролей

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

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

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

Изменения объектов метаданных

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

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

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

• Либо добавить реквизиты непосредственно в объект
• Либо вынести реквизиты в отдельный, связанный с объектом регистр сведений

Второй подход имеет смысл в двух случаях:

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

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

Что делать нельзя, так это удалять существующие реквизиты или сужать состав типов составного реквизита.

В качестве заключения

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

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