Особенности использования "Загрузки измененной конфигурации"
При выполнении загрузки измененной конфигурации система контролирует правильность использования данной функции. Типичной ошибкой является попытка загрузки конфигурации, не являющейся потомком текущей конфигурации. Не смотря на то, что система допускает такое действие, ограничиваясь выдачей предупреждения, настоятельно не рекомендуется выполнять загрузку, если выдано сообщение о том, что "Выбранный файл конфигурации не является потомком…". Это может привести к достаточно серьезным последствиям , например, потере данных или нарушении работоспособности информационной базы.
Основным применением данной функции является модернизация конфигурации параллельно с работой пользователей с информационной базой. Чтобы корректно применять функцию загрузки измененной конфигурации следует придерживаться следующей последовательности действий:
Скопировать конфигурацию функционирующей в организации информационной базы (только файл 1CV7.MD, или всю информационную базу целиком).
Произвести необходимую модификацию конфигурации на скопированной информационной базе или созданной тестовой базе на основе скопированного файла 1CV7.MD.Данная модификация, разумеется, может выполняться многократно. Важно, чтобы в это время не выполнялось никаких изменений в конфигурации работающей в организации информационной базы, включая изменения состава наборов прав, интерфейсов и т.д. Заметим, что список пользователей не является частью конфигурации и, следовательно, может изменяться.
После окончания отладки сделанных в скопированной конфигурации изменений следует открыть конфигурацию работающей информационной базы и выполнить загрузку измененной конфигурации из модифицированной конфигурации. При этом не должно выдаваться сообщение "Выбранный файл конфигурации не является потомком…", так как конфигурация, в которую выполняется загрузка, ни разу не менялась с момента создания копии. После выполнения загрузки измененной конфигурации выполняется сохранение конфигурации с соответствующей реструктуризацией информационной базы.
Если, предполагается продолжать модификацию конфигурации на отдельной информационной базе, то необходимо выполнить повторное копирование полученной после загрузки измененной конфигурации информационной базы или файла 1CV7.MD. Последующую модификацию следует выполнять уже с вновь сделанной копией, а не с той конфигурацией, которая модифицировалась в прошлый раз. Это объясняется тем, что сам факт сохранения после загрузки измененной конфигурации также является изменением конфигурации и отмечается системой, и, следовательно, сделанная ранее копия уже не будет являться прямым потомком работающей конфигурации.
Именно невыполнение последнего пункта описанной последовательности действий приводит обычно к появлению при выполнении загрузки измененной конфигурации предупреждения. Заметим, что в версии 7.7 для решения аналогичной задачи можно использовать механизм объединения конфигураций. Он позволяет выполнять загрузку изменений, даже если конфигурация работающей информационной базы менялась. Однако, использование механизма объединения требует большей аккуратности, так как процесс объединения не столь однозначен, как загрузка измененной конфигурации, вследствие того, что внесенные в работающую конфигурацию и в ее копию изменения могут быть между собой логически не согласованы, что необходимо анализировать в процессе объединения.
Использования режима объединения конфигураций
Рекомендации по использованию режима объединения конфигураций
Основное назначение и дополнительные возможности, предоставляемые режимом объединения конфигураций
Одним из главных назначений режима объединения конфигураций является возможность обновления используемых типовых конфигураций при выпуске очередных релизов.
Кроме того, режим объединения конфигураций позволяет разработчикам прикладных решений, созданных на основе типовых конфигураций, достаточно просто вносить в собственную конфигурацию изменения, которым подверглась типовая конфигурация с момента начала разработки собственной. Ранее использовавшееся в таких случаях средство обновления конфигурации (режим загрузки измененной конфигурации) являлось практически неприменимым, так как после загрузки исчезали все изменения, внесенные разработчиком. Более подробно отличия этих режимов будут рассмотрены в разделе "Отличия режима объединения конфигураций от загрузки измененной конфигурации ".
Однако возможности режима объединения позволяют использовать его и для решения других задач, например, групповой разработки или наследования вновь создаваемой конфигурацией готовых решений, реализованных в других проектах. Интересные применения, например, при сопровождении конфигурации, может иметь также визуализированный список различий в конфигурациях.
Подготовка к объединению конфигураций
Безусловно, процесс объединения конфигураций (особенно существенно различающихся) может быть весьма не простым и потребовать подготовительных действий. В частности, он может быть разбит на несколько этапов, причем для каждого этапа разработчиком может быть выбрана своя стратегия объединения.
Подготовка к объединению конфигураций, прежде всего, заключается в согласовании "терминологии", принятой при разработке конкретных конфигураций, в том, какой идентификатор дан тому или иному объекту метаданных, отражающих одну и ту же физическую сущность. Например, справочник "Сотрудники" в одной конфигурации может быть полным или частичным аналогом справочника "Работники" в другой. Поиск пар объектов, которые сравниваются и, при необходимости, замещаются или объединяются, происходит именно по совпадению идентификаторов. В связи с этим, перед выполнением объединения имеет смысл просмотреть объединяемые конфигурации для проверки того, что применяемые идентификаторы идентичны, при необходимости заменить идентификаторы в одной из конфигураций и внести изменения в тексты модулей и формулы там, где использовались измененные идентификаторы.
Существенную помощь на всех этапах слияния конфигураций могут оказать появившиеся в версии 7.7 возможность получения описания конфигурации в текстовом виде, а также специальные средства, вызов которых осуществляется непосредственно из окна "Объединение конфигураций", а именно кнопка "Сравнить", позволяющая получить развернутую информацию об измененном объекте, и кнопка "Отчет...", при помощи которой можно получить на экране или вывести в файл краткий или детальный отчет о различиях в объединяемых конфигурациях.
В процессе разработки плана объединения может выясниться, что одни объекты метаданных нужно перенести "как есть в загружаемой конфигурации", а для других нужно осуществить "слияние" свойств или выполнять обработку объектов в порядке, отличном, от используемого конфигуратором. В этих случаях процесс объединения разбивается на этапы, причем для каждого, как правило, выбирается своя стратегия. Под стратегией в данном случае понимается совокупность метода объединения (замещение или объединение объектов) и выбор приоритетности конфигураций (текущая или загружаемая).
При выборе стратегии объединения для каждого этапа следует четко понимать, каков будет результат того или иного выбора, т.к. от этого весьма существенно зависит алгоритм обработки каждого объекта.
Основные принципы работы режима объединения конфигураций
Наиболее простой для понимания является использование метода замещения объектов. При выборе этого метода просто происходит замена объекта, определенного в текущей конфигурации на соответствующий из загружаемой, если в текущей выбранный объект имеется, или в текущую конфигурацию выбранный объект добавляется, если объект имеется только в загружаемой. Заметим, что несмотря на то, что при замене объекта происходит, с точки зрения пользователя, удаление имеющегося и добавление нового объекта, это не совсем так, такая замена происходит с минимизацией потери данных, т.е. результат получается тот же, как если бы пользователь открыл объект метаданных для редактирования и вручную привел бы все в соответствие с аналогичным объектом из загружаемой конфигурации, а не удалил бы предварительно объект, а потом вставил, например, из буфера обмена - в этом случае потеря данных была бы полной. Приоритет конфигурации влияет на состав замещаемых объектов. Если в качестве приоритетной конфигурации выбрана текущая , то замещения измененных объектов не происходит, в противном случае они включаются в список замещаемых.
Суть стратегии при выборе метода объединения объектов можно свести к следующей фразе: "При выборе метода объединения объектов конфигуратор стремится к тому, чтобы в результате объединения объект содержал все, что было в нем в текущей конфигурации и все, что было в загружаемой". Слово "стремится" здесь употреблено потому, что для некоторых объектов метаданных (например, "Задача") объединение является бессмысленным, они могут только замещаться.
Следуя этому правилу можно достаточно просто представить себе, что происходит с большинством объектов метаданных при объединении. Такие свойства объекта метаданных, как "синоним", "комментарий" и др. берутся из приоритетной конфигурации, а списочные (такие, например, как список реквизитов) сливаются, то есть их список после объединения будет содержать набор реквизитов обоих конфигураций. Отдельно стоит упомянуть свойства, содержащие массив ссылок на элементы метаданных, такие, например как, список входящих в журнал документов. Подобно списочным свойствам, они сливаются, однако, при этом корректно обрабатывается ситуация, когда ссылка в результате оказывается неразрешенной. Примером может служить случай, если объединяемый (или переносимый) журнал документов содержит ссылки на документы, которые не переносятся из загружаемой конфигурации и отсутствуют в текущей. В этом случае ссылка уничтожается, о чем выдается соответствующая строка в окно сообщений.