При разработке и сопровождении самописных конфигураций на платформе 1С:Предприятие 8.3 одним из наиболее ответственных этапов является обновление Библиотеки стандартных подсистем (БСП). Часто возникает вопрос: обязательно ли последовательно устанавливать каждый промежуточный релиз библиотеки (например, с версии 3.0.2.293 до 3.0.3.341 через все промежуточные сборки) или можно выполнить «прыжок», обновившись сразу на финальный релиз? Разберем этот процесс подробно, проанализируем внутренние механизмы БСП и составим пошаговый план действий.
Рассмотрим основной технический вопрос: как БСП обрабатывает данные при переходе между версиями. Важно понимать различие между обновлением структуры метаданных в Конфигураторе и обновлением данных в пользовательском режиме. Выясним, почему прямое объединение с .cf файлом последней версии является допустимым и безопасным способом для самописных конфигураций.
Проанализируем механизм работы обработчиков обновления. В составе БСП есть специальная подсистема, которая при первом запуске системы после обновления сравнивает текущую версию (хранящуюся в константе СведенияОбОбновленииИБ) с версией, указанной в коде новой конфигурации. Если вы перепрыгиваете через десять релизов, БСП автоматически находит все промежуточные процедуры обновления, которые были созданы разработчиками 1С для каждого пропущенного этапа, и выполняет их строго последовательно. Таким образом, «прыжок» в Конфигураторе не отменяет последовательную трансформацию данных в самой информационной базе.
Рекомендация: Для самописной конфигурации наиболее эффективным методом будет взятие полного .cf файла последней нужной вам версии БСП и выполнение сравнения-объединения. Это сэкономит время и избавит от необходимости многократного повторения рутинных операций в Конфигураторе.
Перед тем как приступить к объединению, крайне важно изучить сопроводительные файлы. Разберем, на что стоит обратить внимание в первую очередь. В папке с установленным шаблоном новой версии БСП всегда присутствует файл UpdateSSL.html. Это ваш главный путеводитель по изменениям.
В этом файле нас интересуют разделы:
Например, рассмотрим ситуацию, когда в новой версии изменяется логика работы с версионированием объектов. В документации может быть указано следующее:
«Изменено размещение общей команды ИсторияИзменений. Теперь она по умолчанию размещается в командной панели формы. Для корректного отображения в формах списков необходимо в процедуре ПриСозданииНаСервере добавить вызов...»
Если проигнорировать эти рекомендации, часть функционала может перестать работать или будет отображаться некорректно. Также часто встречаются предупреждения об устаревших процедурах, например:
// Процедура УстановитьОтображениеЗаголовковГрупп
// модуля СтандартныеПодсистемыСервер помечена как устаревшая.
// Рекомендуется заменить её вызовы на стандартные свойства групп формы.
Посмотрим на один из самых полезных инструментов, который часто игнорируется программистами — внешнюю обработку Maintenance.epf (или аналогичную, находящуюся в каталоге ExtFiles дистрибутива БСП). Этот помощник значительно упрощает процесс адаптации вашей конфигурации под новую версию библиотеки.
Разберем, что именно делает этот инструмент:
Удалить....Проанализируем процесс сравнения и объединения в Конфигураторе. При обновлении самописки, где БСП была модифицирована под нужды бизнеса, обычное объединение «в лоб» может затереть важные правки. Мы рекомендуем использовать трехстороннее сравнение или предварительно выгрузить новую версию БСП в отдельный .cf файл.
Особое внимание уделим Режиму совместимости. Новые версии БСП часто требуют повышения минимальной версии платформы 1С:Предприятие. Перед началом процесса обязательно проверьте файл ReadMe.txt. Если ваша конфигурация работает в режиме совместимости 8.3.12, а новая БСП требует 8.3.16 или выше, библиотека просто не инициализируется, и вы получите ошибку при запуске.
Алгоритм проверки совместимости:
Режим совместимости.После того как объединение в Конфигураторе завершено и база успешно обновлена (клавиша F7), наступает этап выполнения обработчиков в пользовательском режиме. Выясним, почему нельзя сразу отдавать базу пользователям.
В современных версиях БСП (начиная с 3.0) многие тяжелые операции по трансформации данных выполняются в фоновом режиме. Это позволяет системе запуститься быстрее, но функционал, за который отвечают эти обработчики, будет временно недоступен. Нам необходимо:
Если в процессе выполнения обработчиков возникли ошибки, система выведет их в лог. Рассмотрим типичный пример обработки ошибки в коде обработчика:
Процедура ОбновитьДанныеВерсионирования() Экспорт
// Если обработчик упал из-за блокировки данных,
// система повторит его выполнение позже автоматически.
// Но если причина в некорректных данных - потребуется ручная правка.
КонецПроцедуры
БСП придерживается политики «мягкого удаления». Объекты, которые больше не нужны, сначала переименовываются с добавлением префикса Удалить. Рекомендуется не удалять их сразу в момент обновления. Правильным подходом будет дождаться успешного завершения всех обработчиков обновления данных в пользовательском режиме, убедиться в стабильности системы в течение нескольких дней, и только после этого окончательно удалить объекты с префиксом Удалить из метаданных. Это позволит уменьшить размер конфигурации и ускорить работу механизмов сравнения в будущем.
Таким образом, мы выяснили, что последовательное обновление через каждый промежуточный релиз для БСП не является обязательным, если вы используете механизм сравнения-объединения с полным .cf файлом. Главное — внимательно следить за системными требованиями платформы и следовать рекомендациям из UpdateSSL.html по адаптации вашего программного кода. Для автоматической проверки конфигурации на ошибки вызова изменившихся процедур и функций можно использовать инструмент для анализа вызовов методов общих модулей.