Какие действия необходимо выполнить при создании файла обновления конфигурации
Обновлено: 07.07.2024
Исходные материалы:
1. Платформа - 8.1.12.101
2. Конфигурация бухгалтерии, изрядно переписанная от версии 1.6.13.3
3. Версии 1 и 2 этой самой конфигурации.
4. Внимательно изученный материал с ИТС (пример создания и публикации обновления).
Необходимо:
Создать обновление конфигурации с версии 1 на версию 2 с помощью файла обновления *.cfu
Результат:
Не выходит ни фига! Файлы поставки, включая файл *.cfu, создаются нормально, согласно описания.
Да вот беда, - этот *.cfu ни фига не признается версией 1 в качестве обновления!
Пишет: "файл не содержит доступных обновлений." При этом, в табличке указывает - в файле обновление для версии 1.
УМНИКИ И УМНИЦЫ! В чем прикол? Где копать? Кто сталкивался и победил подобное?
сделай файл поставки для версии 1.6.13.3 и укажи его в Конфигурации для обноления при создании файлов поставки. если, конечно, у тебя в переделанной конфигурации конфигурация поставщика 13-ая, а не какая-нибудь восьмая.(1) Т.е., если я правильно тебя понял, надо сначала организовывать обновление от версии 1.6.13.3 на версию 2?
Я-то предполагал, что, обновив конфу файлом *.cf с версии 1.6.13.3 на версию 1, потом запросто смогу обновить версию 1 на версию 2 файлом *.cfu. НЕТ?
(0) я делал так
создаю поставку версии 1
создаю обновление с версии 1 на версию 2, в качестве исходной указываю поставку 1.
снимаю конфу в поддержки полностью.
делаю сравнение объединение с поставкой 1. Она спрашивает: поставить на поддержку? Говорю: да.
После этого обновление проходит нормально.
(3) ЗдОрово! Попробую обязательно!
Насколько я понимаю, сняв, предварительно, конфу с подержки полностью, ты обрубаешь возможные заморочки с поставкой 1С "из центра"?
У меня вот тоже такое подозрение, что фирменная поддержка 1С - какие-то объекты метаданных поддерживаются, какие-то нет (новые, мной созданные) здорово гемороит мою стройную схему :).
Спасибо.
1. создаю поставку типовой, той версии, которая в конфигурации поставщика моей измененной
2. создаю обновление, в качестве конфигурации для обновления указываю поставку из п.1
3. спокойно обновляю стандартными методами.
(3) hhhh, Спасибо еще раз! Наконец-то выбрал время и протестировал твою версию.
Все получилось!
Оказалось, что даже не обязательно снимать конфу с поддержки полностью!
Ключ моих траблов был в том, что я не ставил на конфу поставку версии 1, полагая, будто, раз на конфе уже стоит эта же версия (но только не из поставки. ), то можно сразу обновляться на версию 2.
Другой момент - в конфе я не сравнивал и объединял с поставкой 1, а полностью заменял конфигурацию конфигурацией из файла (из поставки версии 1). В этом случае даже не спрашивает, надо ли ставить на поддержку - сразу ставит поддержку с запретом изменений.
Настройка поставки и создание файлов поставки и обновления
Рассмотрим вопрос подготовки и создания комплектов поставки прикладных решений.
Поставка конфигураций может производится с помощью файлов различных форматов и содержания:
- файл конфигурации ( cf) , содержащий дистрибутив конфигурации;
- файл информационной базы ( 1cd) , содержащий готовую к работе, но пустую базу данных (или заполненную некоторыми обязательными начальными данными);
- файл информационной базы, содержащий демонстрационные данные, соответствующие им файлы выгрузки информационной базы ( dt) .
Для создания конфигурации, которая может быть использована в качестве конфигурации поставщика, необходимо подготовить специальные варианты этих файлов. Основой для них является файл дистрибутива конфигурации ( cf) , подготовка которого будет описана. В конце раздела будет рассмотрен вопрос создания файлов других форматов с помощью файла конфигурации.
Настройка поставки
Настройка поставки позволяет задать правила, по которым будет осуществляться поддержка конфигурации у пользователей. Самыми важными являются правила поставки различных объектов метаданных. Следует обратить внимание, что правила поставки задаются только для объектов верхнего уровня, таких как справочники, документы, регистры. Для объектов метаданных, им подчиненных, таких как реквизиты, табличные части, формы, макеты, будут использоваться соответствующие правила родительских объектов. Напомним, что для объекта можно задать три варианта правила поставки:
- изменения разрешены;
- изменения не рекомендуются;
- изменения запрещены.
Эти варианты определяют допустимые правила поддержки, которые будут устанавливаться пользователем. Более подробно вопрос описан в разделе "Введение в поставку и поддержку конфигураций".
Для объектов так же можно задать правила поставки модулей. Для этого используется флажок "Включать тексты модулей объекта". В случае отмены поставки текстов модулей пользователь не будет иметь возможности просматривать и изменять тексты программ на встроенном языке "1С:Предприятия", что может являться как элементом защиты интеллектуальной собственности поставщика, так и элементом поддержки логической целостности конфигурации.
В настройке поставки конфигурации так же можно установить флажок "Файл поставки может использоваться для обновления". Как было описано в разделе "Введение в поставку и поддержку конфигураций", для обновления конфигурации поставщика могут использоваться как специальные файлы обновления ( cfu ), так и полные файлы конфигурации ( cf). Сброс данного флажка отменяет последнюю возможность. Это может быть полезно, когда новая версия конфигурации требует сложной обработки базы данных.
Например, изменение типа реквизита справочника со строки на ссылку на другой справочник требует "двухпроходного обновления". Сначала требуется добавить новый реквизит типа ссылки, заполнить его на основе значения старого реквизита, и только потом можно удалить старый реквизит, а новый переименовать. Такую процедуру нельзя выполнить в рамках одного изменения структуры базы данных с предшествующим и / или последующим выполнением специальной обработки. Требуется подготовить промежуточную версию конфигурации, в которой новый реквизит будет добавлен, а старый еще не удален, и написать соответствующие обработки. Процедуру обновления конфигурации в этом случае, конечно, следует подробно описать в документации, но всегда существует вероятность ошибочных действий со стороны пользователя. Использование флажка "Файл поставки может использоваться для обновления" позволяет поставщику подстраховаться от ошибок пользователя в процессе обновления. Общая схема может быть примерно такой:
- Подготавливается файл обновления конфигурации с предыдущих версий до промежуточной.
- Подготавливается файл обновления конфигурации с промежуточной (только) версии до конечной.
- Подготавливается файл конфигурации с отключенным флажком "Файл поставки может использоваться для обновления".
Пользователь, имеющий конфигурацию старой версии, не сможет нарушить правильный порядок обновления, поскольку, даже если он получит файл конфигурации новой версии, выполнить с помощью него обновление он не сможет. Однако следует иметь в виду недостаточную гибкость этого средства. При его отключении пользователь не сможет при необходимости выполнить "обратное обновление" с более поздней версии. По умолчанию флажок "Файл поставки может использоваться для обновления" включен.
Стандартная структура каталогов файлов поставки и обновления
Механизм поставки конфигураций предлагает определенную схему размещения на диске файлов поставки и поддержки разных версий. В диалоге "Создание файлов поставки и обновления конфигурации" нажав кнопку "Каталог файлов поставки" можно задать корневой каталог для размещения создаваемых файлов. Файлы поставки и обновления будут по умолчанию располагаться в подкаталогах, имеющих имена, соответствующие свойству "Версия" конфигурации. Использование этой схемы позволит упростить подготовку обновлений для новых версий конфигурации, как это будет описано ниже. Следует иметь ввиду, что корневой каталог не сохраняется внутри самой конфигурации и будет изменен при переносе файла информационной базы "1 cd " на другой компьютер.
Создание файлов поставки и обновления конфигурации
Файлы поставки и обновления могут создаваться как одновременно, так и раздельно, из диалога "Создание файлов поставки и обновления". Но одновременно может быть создан только один файл обновления. Для создания нескольких файлов обновления с разного набора предыдущих версий следует выполнить процедуру создания файлов обновления несколько раз. Файл поставки при этом может быть создан только однажды. Впрочем, отказ от создания файла поставки не приведет к ускорению создания файла обновления. В случае конфигурации большого объема это достаточно длительный процесс, время исполнения которого зависит от количества выбранных версий, подлежащих обновлению.
При включении флажка "Создать файл обновления конфигурации" следует указать один или несколько файлов предыдущих версий, для которых и будет подготовлено обновление. Следует напомнить что, как было описано в разделе "Введение в поставку и поддержку конфигураций", файлы обновления не являются кумулятивными, то есть создание обновления с версии "4" до версии "6" не позволит с помощью этого файла произвести обновление с версии "5", если только она не была указана при создании. Для выбора файлов предыдущих версий можно пользоваться как кнопкой "Добавить" и прямым выбором файла, так и кнопкой "Добавить из предыдущих версий", которая сама найдет и предложит для выбора файлы, если они были размещены на диске в соответствии с описанной выше стандартной структурой каталогов. С помощью команды "Добавить" можно указать и файлы других конфигураций. После чего обновление может быть выполнено и для них, однако это должны быть именно файлы поставки, а не произвольные файлы конфигурации.
Создание файлов поставки других форматов
Как было отмечено в начале раздела, созданный файл поставки конфигурации ( cf) должен являться основой для всех других файлов поставки. Рассмотрим подготовку файла информационной базы (1 cd) , содержащего, например, демонстрационные данные. Демонстрационную базу можно подготовить отдельно, пользуясь при этом, например, конфигурацией, полученной обычной выгрузкой из информационной базы, в среде которой осуществляется разработка дистрибутива. Конфигурации не обязательно должны быть строго идентичными, но расхождения между ними должны позволять производить обновление конфигурации базы данных (и самих данных) без проблем.
Открыв в режиме конфигуратора файл информационной базы, содержащий необходимые данные, следует выполнить команду "Конфигурация\Загрузить конфигурацию из файла. ", согласиться на замену текущей конфигурации и выполнить обновление конфигурации базы данных. Полученную в результате информационную базу можно использовать для поставки. Для подготовки файла выгрузки конфигурации ( dt ) следует в ее среде выполнить стандартную команду "Администрирование\Выгрузить информационную базу".
Для основных объектов с дереве конфигурации, напр. справочники, документы, регистры, отчеты и др можно задавать правила поставки. Для реквизитов используются соответствующие правила родительских объектов. Есть 3 варианта правил поставки (изменения разрешены, изменения не рекомендуются, изменения запрещены), которые определяют допустимые правила поддержки.
Для открытия настройки поставки :
В открывшемся окне можно задать правила поставки модулей:
Флажок "Файл поставки может использоваться для обновления" по умолчанию включен. Он используется для недопущения обновления с файла конфигурации, когда должен быть соблюден четкий порядок последовательности обновления (например, изменение типа реквизита).
Открытие диалогового окна при нажатии кнопки «Изменить подчиненные» применяет выбранное правило ко всему дереву объектов:
В случае отмены включения в поставку текстов модулей объекта, у пользователя не будет возможности просматривать и изменять их тексты. Такую настройку можно использовать для защиты интеллектуальной собственности поставщика.
Для создания файлов поставки и/или обновления нужно в меню «Конфигурация» нажать кнопку «Создать файлы поставки и обновления конфигурации…»
Создадим файл поставки предыдущей конфигурации, предварительно задав по кнопке «Каталог файлов поставки» каталог для создания данных файлов.
Затем загрузим новую конфигурацию и для нее также в указанном ранее каталоге создадим файлы поставки и обновления.
При этом нужно указать один или несколько файлов предыдущих версий, для которых будет подготовлено обновление.
Если создать файл поставки в той конфигурации, которая находится у самой себя на поддержке, то при подготовке очередной версии поставки нужно использовать только новый файл конфигурации *.cf. Только так обновленная конфигурация, находящаяся на поддержке, может быть правильно обновлена.
Создадим комплект поставки и добавим файл обновления. Также можно добавить и файл описания обновления в формате *.htm, *.html
Добавим вариант поставки:
Изменим наименование варианта поставки и выберем поставляемые файлы, нажав на «Редактировать».
Нажимаем «Создать файлы комплекта» и выбираем наше обновление:
После нажатия кнопки ОК выбираем каталог размещения комплекта поставки. При этом создается 2 файла: файл тип обновления конфигурации и файл тип манифест конфигурации ИБ.
Открываем «Поддержка»-«Шаблоны конфигураций и обновлений» и создаем файл списка шаблона путем нажатия одноименной кнопки.
Поставка конфигураций 1С может производится с помощью файлов различных форматов и содержания:
- файл конфигурации ( cf) , содержащий дистрибутив конфигурации;
- файл информационной базы ( 1cd) , содержащий готовую к работе, но пустую базу данных (или заполненную некоторыми обязательными начальными данными);
- файл информационной базы, содержащий демонстрационные данные, соответствующие им файлы выгрузки информационной базы ( dt) .
Для создания конфигурации, которая может быть использована в качестве конфигурации поставщика, необходимо подготовить специальные варианты этих файлов, основой для которых является файл дистрибутива конфигурации ( cf) .
В "1С:Предприятии 8" любая конфигурация может стоять на поддержке одной или нескольких других конфигураций, называемых конфигурациями поставщика.
В качестве конфигурации поставщика может выступать конфигурация, созданная командой меню "Конфигурация" - "Поставка конфигурации" - "Создать файлы поставки и обновления конфигурации".
В результате выполнения этой команды создается файл конфигурации (. cf) .
Файл, подготовленный командой "Конфигурация" - "Сохранить конфигурацию в файл", в качестве конфигурации поставщика использовать нельзя.
Для того чтобы получить конфигурацию поставщика в виде файла информационной базы (.1cd) или файла выгрузки информационной базы (.dt), требуется:
- подготовленный вышеописанным способом файл . cf загрузить в требуемую информационную базу (возможно, в пустую), выполнив команду "Конфигурация" - "Загрузить конфигурацию из файла";
- затем, при необходимости, штатными средствами создать файл . dt.
Настройка поставки 1С
Настройка поставки (команда меню "Конфигурация" - "Настройка поставки. ") позволяет задать правила, по которым будет осуществляться поддержка конфигурации у пользователей.
Следует обратить внимание:
- правила поставки задаются только для объектов верхнего уровня: справочники, документы, регистры;
- для подчиненных им объектов метаданных (реквизиты, табличные части, формы, макеты) будут использоваться соответствующие правила родительских объектов.
Правила поставки объекта конфигурации:
- изменения разрешены;
- изменения не рекомендуются;
- изменения запрещены;
- включение в конфигурацию не рекомендуется.
Эти варианты определяют допустимые правила поддержки, которые будут устанавливаться пользователем.
Правила поставки модулей объекта:
- используется флаг "Включать тексты модулей объекта". В случае отмены поставки текстов модулей пользователь не будет иметь возможности просматривать и изменять тексты программ на встроенном языке "1С:Предприятия", что может являться как элементом защиты интеллектуальной собственности поставщика, так и элементом поддержки логической целостности конфигурации.
Отмена использования при поставке полного файла конфигурации (. cf):
- установка флага "Файл поставки может использоваться для обновления" в настройке поставки конфигурации отменяет возможность использования для обновления конфигурации поставщика полных файлов конфигурации (. cf). Это может быть полезно, когда новая версия конфигурации требует сложной обработки базы данных. По умолчанию флаг "Файл поставки может использоваться для обновления" включен.
Например, изменение типа реквизита справочника со строки на ссылку на другой справочник требует "двухпроходного обновления":
- сначала требуется добавить новый реквизит типа ссылки, заполнить его на основе значения старого реквизита;
- только потом можно удалить старый реквизит, а новый переименовать.
Такую процедуру нельзя выполнить в рамках одного изменения структуры базы данных с предшествующим и (или) последующим выполнением специальной обработки. Требуется подготовить промежуточную версию конфигурации, в которой новый реквизит будет добавлен, а старый еще не удален, и написать соответствующие обработки.
Процедуру обновления конфигурации в этом случае, конечно, следует подробно описать в документации, но всегда существует вероятность ошибочных действий со стороны пользователя.
Использование флажка "Файл поставки может использоваться для обновления" позволяет поставщику подстраховаться от ошибок пользователя в процессе обновления.
Общая схема может быть примерно такой:
- Подготавливается файл обновления конфигурации с предыдущих версий до промежуточной.
- Подготавливается файл обновления конфигурации с промежуточной (только) версии до конечной.
- Подготавливается файл конфигурации с отключенным флажком "Файл поставки может использоваться для обновления".
Пользователь, имеющий конфигурацию старой версии, не сможет нарушить правильный порядок обновления, поскольку, даже если он получит файл конфигурации новой версии, выполнить с помощью него обновление он не сможет.
ВАЖНО! Следует иметь в виду недостаточную гибкость этого средства. При его отключении пользователь не сможет при необходимости выполнить "обратное обновление" с более поздней версии.
Стандартная структура каталогов файлов поставки и обновления 1С
Механизм поставки конфигураций предлагает определенную схему размещения на диске файлов поставки и поддержки разных версий. В диалоге "Создание файлов поставки и обновления конфигурации" нажав кнопку "Каталог файлов поставки" можно задать корневой каталог для размещения создаваемых файлов. Файлы поставки и обновления будут по умолчанию располагаться в подкаталогах, имеющих имена, соответствующие свойству "Версия" конфигурации.
Рисунок "Создание файлов поставки и обновления конфигурации"
Использование этой схемы позволит упростить подготовку обновлений для новых версий конфигурации.
Следует иметь ввиду, что корневой каталог не сохраняется внутри самой конфигурации и будет изменен при переносе файла информационной базы "1 cd " на другой компьютер.
Создание файлов поставки и обновления конфигурации
Файлы поставки и обновления могут создаваться из диалога "Создание файлов поставки и обновления":
- одновременно (только один файл обновления);
- раздельно.
Для создания нескольких файлов обновления с разного набора предыдущих версий следует выполнить процедуру создания файлов обновления несколько раз. Файл поставки при этом может быть создан только однажды. Впрочем, отказ от создания файла поставки не приведет к ускорению создания файла обновления. В случае конфигурации большого объема это достаточно длительный процесс, время исполнения которого зависит от количества выбранных версий, подлежащих обновлению.
При включении флажка "Создать файл обновления конфигурации" следует указать один или несколько файлов предыдущих версий, для которых и будет подготовлено обновление.
ВАЖНО! Файлы обновления не являются кумулятивными, то есть создание обновления с версии "4" до версии "6" не позволит с помощью этого файла произвести обновление с версии "5", если только она не была указана при создании.
Для выбора файлов предыдущих версий можно пользоваться:
- кнопкой "Добавить" и прямым выбором файла;
- кнопкой "Добавить из предыдущих версий", которая сама найдет и предложит для выбора файлы, если они были размещены на диске в соответствии с описанной выше стандартной структурой каталогов.
С помощью команды "Добавить" можно указать и файлы других конфигураций. После чего обновление может быть выполнено и для них, однако это должны быть именно файлы поставки, а не произвольные файлы конфигурации.
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Введение в поставку и поддержку конфигураций
Рассмотрим типичную ситуацию. Фирма-поставщик выпускает тиражную конфигурацию. Клиент приобретает ее и адаптирует под свои требования. Через некоторое время поставщик выпускает новую версию, и перед клиентом встает вопрос обновления, то есть интеграции своих изменений с изменениями поставщика. Ручное объединение в подобных случаях очень трудоемко. Требуется составить список всех отличий своей конфигурации от старой конфигурации поставщика и заново внести их в новую версию. Можно делать и наоборот, то есть подготовить список изменений поставщика и внести их в свою конфигурацию, но это ничего не меняет. Многое также зависит от механизма сравнения конфигураций и подготовки отчета различий. В платформе "1С:Предприятие" версии 8 этот механизм был существенно улучшен по сравнению с "1С:Предприятием" версии 7.7, но даже самый лучший и подробный отчет от дальнейшей утомительной ручной работы не освобождает. Механизм поставки и поддержки конфигураций в значительной степени автоматизирует этот процесс.
Общая схема обновления
Подробно рассмотрим ситуацию на примере любого свойства объекта метаданных. Возможны следующие варианты:
| Пользователь | Поставщик | Правило обновления | |
| 1 | Менял | Не менял | Взять из конфигурации пользователя |
| 2 | Менял | Менял | ? |
| 3 | Не менял | Не менял | Взять из конфигурации пользователя |
| 4 | Не менял | Менял | Взять из конфигурации поставщика |
Таблица 1. Правила обновления по умолчанию
Нетрудно заметить, что варианты 1, 3, 4 в большинстве случаев не требуют модифицировать предложенное правило. Самый сложный случай – второй. Здесь нельзя сделать никаких предположений, но можно по крайней мере автоматически определить все такие свойства и предоставить пользователю отфильтрованный список для указания правила в каждом конкретном случае.
Реализация в платформе "1С:Предприятие 8"
Общие понятия
В "1С:Предприятии 8" любая конфигурация может стоять на поддержке одной или нескольких других конфигураций, называемых конфигурациями поставщика. В качестве конфигурации поставщика может выступать конфигурация, созданная командой Конфигурация - Поставка конфигурации - Создать файлы поставки и обновления конфигурации . В результате выполнения этой команды создается файл конфигурации ( cf) . Файл, подготовленный командой Конфигурация - Сохранить конфигурацию в файл , в качестве конфигурации поставщика использовать нельзя. Для того чтобы получить конфигурацию поставщика в виде файла информационной базы (1cd) или файла выгрузки информационной базы (dt), требуется подготовленный вышеописанным способом файл cf загрузить в требуемую информационную базу (возможно, в пустую), выполнив команду Конфигурация - Загрузить конфигурацию из файла . Затем, при необходимости, можно штатными средствами создать файл dt.
Существуют два способа встать на поддержку конфигурации поставщика. Первый - использовать конфигурацию, подготовленную вышеописанным способом (при необходимости внося в нее изменения). Фактически подготовленная конфигурация поставщика находится на поддержке той конфигурации, в которой она была создана. Аналогичный результат достигается через команды Конфигурация - Загрузить конфигурацию из файла и Администрирование - Загрузить информационную базу . Второй способ позволяет поставить на поддержку уже созданную конфигурацию пользователя. Для этого необходимо выполнить команду Конфигурация - Сравнить, объединить с конфигурацией из файла . Если в качестве выбранного файла указывается файл конфигурации поставщика, и конфигурация пользователя уже не находится на ее поддержке, предлагается после объединения встать на поддержку.
Существуют два режима поддержки. Первый - в конфигурацию поставщика не вносятся изменения, она используется как есть. Такой режим возможен только при первом способе постановки на поддержку, и именно в нем конфигурация поставщика находится после ее создания. Все объекты конфигурации в этом случае заблокированы для изменений (в том числе и для добавления новых объектов). Второй режим - конфигурация находится на поддержке с возможностью изменений. Для того чтобы перейти в этот режим, необходимо открыть диалог настройки поддержки командой Конфигурация - Поддержка - Настройка поддержки и нажать кнопку Включить возможность изменения .
Способы обновления конфигурации. Обновление конфигурации может выполняться как с помощью файлов конфигурации поставщика новой версии, так и с помощью специальных файлов обновления конфигурации ( cfu) . Обновление конфигурации с помощью файлов (cf) может выполняться с любой версии (в том числе и более новой, при необходимости отказаться от внесенных изменений). При создании файла обновления поставщик указывает, для каких версий конфигурации он предназначен. Таких версий может быть несколько, но обновление может быть выполнено только с них. Это связано с тем, что файлы обновления включают в себя не всю конфигурацию, а только те изменения, которые существуют между конечной версией и указанными при создании файла обновлениями. Важно отметить, что файлы cfu не поддерживают обновления не только для более ранних версий конфигурации, чем они предназначены, но и для более поздних.
Приведем пример. Если конечная версия "4", а обновление создается только для версии "2", то невозможно будет выполнить обновление не только для версии "1", но и для версии "3". Такое ограничение связано с возможностью "обратных" изменений. То есть представим себе, что при переходе к версии "3" поставщик увеличил длину строки в типе реквизита, а в версии "4" изменил ее обратно. При подготовке обновления "2" - "4" это свойство в файл не попадет (поскольку в этих версиях значения совпадают). Если позволить использовать такой файл для обновления версии "3", то у пользователя окажется неправильная, увеличенная длина строки. Файлы обновления конфигурации имеют минимальный размер не только за счет включения в них только необходимых объектов, но и за счет применяемого в них сжатия данных. Они оптимальны для доставки обновления пользователю по низкоскоростным каналам связи. Обратной стороной является описанная выше меньшая гибкость их применения. С точки зрения дальнейшего процесса обновления применение файлов cf и cfu ничем не отличается.
Рисунок 1. Общая схема взаимодействия поставщика и пользователя
Выполнение обновления
Если конфигурация пользователя находится на поддержке без возможности внесения изменений, обновление представляет собой тривиальный, полностью автоматизированный процесс. Пользователь выполняет команду Конфигурация - Поддержка - Обновить конфигурацию , и после получения подтверждения выполняется обновление. Рассмотрим второй, наиболее интересный случай. Пользователь включил возможность изменения. Обновление конфигурации производится с использованием стандартного механизма сравнения и объединения, но пользователю предоставляется существенный дополнительный сервис. В процессе сравнения участвуют не две а три конфигурации - конфигурация пользователя, старая конфигурация поставщика (она хранится в конфигурации пользователя) и новая конфигурация поставщика, до которой и производится обновление. При этом система автоматически производит анализ сделанных изменений и, в соответствии с таблицей 1, расставляет правила объединения. Главную сложность представляет собой вариант 2, когда и пользователь, и поставщик меняли одно и то же свойство. Как отмечалось, разумных предположений автоматически сделать невозможно, но можно выделить эти случаи для пользователя. Все подобные свойства в дереве объединения показываются жирным шрифтом. Кроме того, в настройке фильтра просмотра можно указать флажок Показывать только дважды измененные свойства , и в дереве объединения будут показываться только те свойства, которые требуют ручной установки правил объединения. После выполнения объединения хранимая внутри пользовательской конфигурации конфигурация поставщика будет обновлена до новой версии.
Модификация алгоритма обновления с помощью правил поддержки
Пользователь может модифицировать приведенный алгоритм обновления с помощью правил поддержки, которые можно установить для каждого объекта метаданных. Необходимость в этом может возникнуть, если пользователь собирается самостоятельно выполнять дальнейшую модификацию объекта на себя и ему неинтересны изменения, вносимые поставщиком. Частный случай - пользователю вообще не требуется данный объект, и он хочет его удалить. Существуют три правила поддержки объекта метаданных:
- "Объект поставщика не редактируется" - пользователь не может изменять объект поставщика. Основное предназначение этого правила будет описано ниже, но пользователь может установить его с целью страховки от случайных изменений. При обновлении такие объекты будут полностью заменяться на объекты поставщика новой версии.
- "Объект поставщика редактируется с сохранением поддержки" - основное правило. В этом случае алгоритм объединения в точности совпадает с описанным.
- "Объект поставщика снят с поддержки" - пользователь не хочет выполнять дальнейшие обновления данного объекта. Для того чтобы удалить объект поставщика, предварительно ему необходимо установить данное правило.
Приведем расширенный вариант таблицы 1, с учетом правил поддержки.
| Пользователь | Поставщик | Правила поддержки и обновления | |||||||
| 1 | Менял | Не менял |
| ||||||
| 2 | Менял | Менял |
| ||||||
| 3 | Не менял | Не менял |
| ||||||
| 4 | Не менял | Менял |
|
Таблица 2. Правила обновления по умолчанию с учетом правил поддержки
Ограничения действий пользователя со стороны поставщика с помощью правил поставки
Поставщик может ограничить возможные изменения пользователя с помощью правил поставки, которые можно устанавливать для каждого объекта метаданных. Данная возможность призвана ограничить возможные изменения конфигурации поставщика, нарушающие логику ее работы, после которых дальнейшая поддержка конфигурации теряет смысл. Существуют три правила поставки:
- "Изменения разрешены";
- "Изменения не рекомендуются";
- "Изменения запрещены".
Далее приводятся правила поддержки (по умолчанию и доступные для выбора пользователем), соответствующие различным правилам поставки.
Читайте также: