Прочитав заголовок, многие сразу скажут про то, что такого "Комбайна" не существует и существовать не может!
Соглашусь с ними, потому что полностью автоматизировать данный процесс не удаётся. Но это не совсем так!
Задача: имеем УТ версии 11.4.6.174, необходимо обновить до версии 11.4.12.75 с сохранением добавленных объектов, реквизитов и кода, привести её к полностью типовой и вынести все доработки в расширение.
Решение:
Сразу оговорюсь! - От конфигурации железа очень зависит скорость обновления, а так же от размера базы (имеется в виду не Вес, а количество времени учёта в ней и активности использования).
Решено было привести её к типовой версии 11.4.6.174 загрузкой конфигурации из файла CF типового релиза.
И вот тут появилась первая проблема: принять изменения в базе не удаётся - записи регистров сведений стали неуникальны (Регистры: РеестрДокументов и ДанныеПервичныхДокументов). Тут нам приходит на помощь обработка ЧисткаЛюбогоРегистраСведений, где мы и почистим эти регистры. Страшного тут ничего и при дальнейшем обновлении они заполнятся данными под новые версии (согласен с тем, что лучше так не делать и просто "прокатило" в данной ситуации).
Спросите вы: "А как же дальше? Обновлять по шагам до финала?" - отвечу что: "Нет, но в 2 шага!".
Делаем тестовое обновление на Финальную (11.4.12.75) и при запуске ловим ошибку, что до неё можно обновляться не менее чем с 11.4.7 ветки. Поэтому решено обновиться с 11.4.6.174 до 11.4.7.128.
И тут есть два подхода:
Первый: Обновиться файлом CF релиза 11.4.7.128.
Второй: Сделать накопительное обновление самостоятельно с 11.4.6.174 на 11.4.7.128.
Первый вариант итак всем понятен и рассматриваться не будет, а второй рассмотрим подробнее.
1. Разворачиваем пустую базу версии 11.4.7.128.
2. Заходим в конфигуратор: "Конфигурация" - "Поставка конфигурации" - "Создать файлы поставки и обновления конфигурации...".
3. На предупреждение отвечаем "Да", снимаем галку "Создать файл поставки" (он нам не нужен - получится типовой CF этой же версии), справа от пункта "Добавить из предыдущих версий" нажимаем "+" и выбираем CF релиза 11.4.6.174. Жмём "Выполнить".
Итак у нас готово накопительное обновление с 11.4.6.174 на 11.4.7.128 (CFU файл).
То же самое повторяем для создания обновления с релиза 11.4.7.128 на 11.4.12.75.
Обновляем нашу конфигурацию на релиз 11.4.7.128. Запускаем базу и проходят обработки применимые только для перехода на последний релиз!
Как же быть? - Ответ есть и это типовой механизм, предусмотренный в БСП!
Запускаем обработку ВыполнитьОтложенноеОбновлениеСейчас и нажимаем единственную кнопку, которая запускает обработчики обновления последовательно как в релизах, если бы мы обновлялись по каждому из обновлений последовательно.
Подмечу: да, можно было бы это выполнить в фоне, а не заставлять висеть несколько часов интерфейс "мёртвым", но так делать не нужно!
Объясню почему: нам нужно чтобы обработчики обновлений полностью отработали иначе дальнейшее обновление может быть невозможно! Поэтому запускаем и ждём до победного окончания (отвисания).
Теперь есть другой вопрос: "А как же перенести доработки? Мы же их полностью затёрли!".
Ответ очень прост, хоть и требует внимательности при выполнении данного шага.
Открываем 2 конфигуратора: типовую 11.4.6.174 и 11.4.6.174 текущую доработанную.
В текущей доработанной запускаем сравнение с конфигурацией поставщика.
Ставим фильтр на добавленные.
1. Создаём пустое расширение в типовой пустой релиза 11.4.6.174
2. Добавляем эти объекты в расширение.
3. Зажимаем кнопку мыши с добавленного и переносим в расширение (если Левая - происходит сразу копирование, если Правую - то "Скопировать" ещё нужно отдельно нажать.
Был бы признателен за комментарий как сделать проще: перенести Добавленную структуру в Расширение из Доработанной.
Предпринимал попытки выгрузить конфигурацию и расширение в файлы и потом "колдовать" с XML файлами которые хотел обратно загрузить в Расширение из файлов, но у меня это не получилось.
Итак - расширение по структуре полностью повторяет наши доработки. Не буду останавливаться на том что были Константы и их пока нет возможности вынести на расширение, но предлагаю подумать про их замену, например на Справочник или Регистр. Не буду рассматривать что и когда нужно. Нужно почитать "как и в каких случаях" делают другие или уже иметь базовые знания по всем объектам метаданных и их назначению.
Перенос осуществлялся двумя способами:
1. Типовой обработкой ВыгрузкаЗагрузкаДанныхXML для полностью новых и добавленных объектов.
2. Обработкой ВыгрузкаЗагрузкаРеквизитов.
Расскажу как ей пользоваться:
Когда структура перенесена в расширение, в этой базе запускаем обработку, переходим во вкладку "Набор" и нажимаем "Заполнить по расширению".
Заполняется список по всему добавленному теперь уже в Расширение.
Теперь сохраняем настройки в файл.
Открываем эту же обработку в Доработанной и загружаем настройки из файла на этой вкладке и нажимаем кнопку "Выгрузить".
Данную выгрузку загружаем уже в новой базе с реквизитами на расширении.
Внимание! Обработка переносит тип данных и ищет ссылочные по их Уникальному идентификатору. Позаботьтесь о переносе справочников и других ссылочных данных - заранее!
Но история на этом не заканчивается.
На обновление уходило больше двух суток и необходимо было реагировать на запуск следующих по плану пунктов!
Было решено сделать правила в Конвертации данных 2 для переноса оставшихся данных и изменения уже перенесённых. Выбор пал на автоматическое сопоставление, так как при тестировании были проблемы с тем что документы не проводятся автоматически и требуют дополнительных действий для проведения - быстрее было запилить обработку.
Расширение ПроведениеВФоне и обработка ДопровестиПерепровести позволяет это сделать.
Механизм прост. Пример документ "Заказ клиента". Ругается на то, что не заполнены Этапы графика оплат.
В столбце ищем "Имя" документа, а в "Действие" добавляем код необходимый для заполнения перед проведением.
Для Заказа клиента он таков:
ДокОбъект.ЗаполнитьЭтапыГрафикаОплаты();
ДокОбъект - эта переменная встроена в обработку и содержит экземпляр обрабатываемого объекта.
Но и это не конец истории!
Документы прошлых периодов тоже правились! И представьте в ноябре была правка в документ сентября!
Как быть? Переносить всё с сентября и перепроводить?
Нет, есть способ лучше!
Допишем в правила обмена следующее:
Добавим параметры:
ДатаНачала, ДатаОкончания и ТолькоИзмененныеВПериоде.
В обработчик "Перед выгрузкой данных" добавим код:
Если Параметры.ТолькоИзмененныеВПериоде И ЗначениеЗаполнено(Параметры.ДатаНачала) И ЗначениеЗаполнено(Параметры.ДатаОкончания) И Параметры.ДатаОкончания >= Параметры.ДатаНачала Тогда
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| ВерсииОбъектов.Объект КАК Объект
|ИЗ
| РегистрСведений.ВерсииОбъектов КАК ВерсииОбъектов
|ГДЕ
| ВерсииОбъектов.ДатаВерсии МЕЖДУ &ДатаНачалаВерсии И &ДатаОкончанияВерсии
| И ВерсииОбъектов.Объект.Дата МЕЖДУ &ДатаНачалаПериода И &ДатаОкончанияПериода
|
|УПОРЯДОЧИТЬ ПО
| Объект";
//Параметры задают Период в который изменяли объекты
Запрос.УстановитьПараметр("ДатаНачалаВерсии", НачалоДня(Параметры.ДатаНачала));
Запрос.УстановитьПараметр("ДатаОкончанияВерсии", КонецДня(Параметры.ДатаОкончания));
//Период с формы за который выгружаем объекты
Запрос.УстановитьПараметр("ДатаНачалаПериода", НачалоДня(ДатаНачала));
Запрос.УстановитьПараметр("ДатаОкончанияПериода", КонецДня(ДатаОкончания));
Результат = Запрос.Выполнить().Выгрузить();
Параметры.Вставить("ТаблицаДокументов",Результат);
КонецЕсли;
В обработчик "Перед выгрузкой объекта" такой:
Если Параметры.ТолькоИзмененныеВПериоде Тогда
МетаданныеОбъекта = Метаданные.НайтиПоТипу(ТипЗнч(Объект));
Если Метаданные.Документы.Содержит(МетаданныеОбъекта) Тогда //Это документ
Если Параметры.ТаблицаДокументов.Найти(Объект.Ссылка) = Неопределено Тогда
Отказ = истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
Что нам это даёт:
Выгружая сентябрь, например, мы указываем, что изменения должны были произойти потом, в ноябре, например.
Указывая Период выгрузки - Сентябрь параметры быть должны например такими:
ДатаНачала = Начало Ноября
ДатаОкончания = Конец Ноября
ТолькоИзмененныеВПериоде = Истина
Так мы выгрузим документы за Сентябрь, изменённые в Ноябре, но это возможно лишь при включенной функциональности Версионирования объектов.
Так как мы отказались от проведения документов в конвертации, то так же их ищем по версиям объектов и ПереПроводим.
Итак. Вроде бы готово!..
Но пора идти и дальше!
Обновляем 11.4.12.75 до 11.4.13.103.
Тут нам говорят про сопоставление модулей только с помощью внешней программы!
Тут я был поражён... Оказывается таким инструментом можно было пользоваться очень давно!
Ставим KDiff3 и добавим ровно одну настройку: в настройках внешней программы в конце дописываем:
--cs "ShowInfoDialogs=0"
Если мало чего сравнивать/объединять/обновлять/сопоставлять, то окно что программа сама за нас справилась появится несколько раз что всё успешно, но когда таких объектов много...
Лично я писал Кликер по кнопке ОК, пока не узнал об этой настройке.
Добавлю: ИзменениеИКонтроль лучше делать "с нуля" ещё раз пробежавшись по коду.
Плохим примером служит вставка своего кода в Пустую строку! Обязательно делайте отступ на новую везде!
Проблема такого метода - запросы, их всё равно надо потом проверять! Так как Вставки в запрос плохи тем, что запрос мог сильно поменяться (новые или удалённые таблицы) и вставки добавятся к другой таблице! В отличии от кода которым просто не отработает или задублируется. В случае с запросом же - это будет ошибка на которой будет падать - всё!
В заключение добавлю:
Будет ещё статья где опишу: обновление конфигурации, где ещё не было НДС 20% и режим совместимости не позволял влезать в модули делать много нужного, а повышение версии совместимости - ломает полностью базу и делает невозможность работы в ней.
