От экспертов «1С‑Рарус»: Практика миграции данных из 1С:Документооборот редакции 2.1 в 3.0. Часть 1

Введение

Сегодня мы с вами поговорим о переходе и процессе миграции данных из системы «1С:Документооборот 2.1» в систему «1С:Документооборот 3.0». Расскажем как прошли этот путь на одном из проектов, опишем нюансы подсистем участвующих в процессе миграции, постараемся поведать о подводных камнях, которые обнаружили, о трудностях с которыми столкнулись и как их решили.

Информации получилось достаточно много, поэтому статья будет состоять из двух частей.

Термины и определения

• ДО2 — 1С:Документооборот 2.1;
• ДО3 — 1С:Документооборот 3.0;
• ФО — функциональная опция.

Постановка задачи

У одного из наших клиентов возникла необходимость обновить базу с конфигурацией «1С:Документооборот» с версии 2.1 на версию 3.0. На первый взгляд чего уж проще, накатываем обновление и радуемся. Но увы, хоть в заголовке обозначен тот же самый продукт, по факту при смене первой цифры редакции версии — метаданные этих двух конфигураций настолько сильно стали отличаться, что можно считать их разными продуктами. И как в случае перевода учета между разнородными системами, прямого обновления между этими версиями не предусмотрено.

Но специально для такого случая в эти конфигурации встроена система, позволяющая произвести процесс миграции — то есть перенос данных из текущей учетной базы в новую пустую базу 1С:Документооборот 3.0.

Общее описание процесса миграции

Общая схема процесса миграции

Забегая вперед приведем общую схему миграции из ДО2 в ДО3.

Далее данная схема будет поблочно рассмотрена с подробностями.

Итак, миграция — это перенос данных из одной базы в другую.

Начнем с того, что сам процесс может быть растянут во времени и при этом не обязательно подразумевает остановку работы пользователей в исходной базе (ДО2). В связи с этим данные для миграции внутри исходной базы можно разделить на две части:

1. Исторические данные — то есть объекты, существующие на момент старта миграции (далее «История»).
2. Данные, измененные пользователями уже после старта миграции (далее «Дельты»).

Соответственно и длительность самой миграции этих частей будет зависеть от разных параметров, для Истории — от общего объема данных базы, для Дельт — от интенсивности изменения объектов пользователями.

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

• Выгрузка Истории из ДО2 в файлы.
• Выгрузка Дельт из ДО2 в файлы.
• Загрузка файлов Истории в ДО3.
• Загрузка файлов Дельт в ДО3.

Процессы загрузки и выгрузки напрямую друг с другом не связаны, выполняются асинхронно. Но есть общее правило — обработка Дельт в обоих случаях следует только после обработки Истории.

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

Далее опишем основные этапы миграции на стороне выгрузки ДО2 и на стороне загрузки ДО3. А также подробно расскажем о подсистеме «Отметок времени», так как она занимает ключевую роль в учете Дельт, возникающих в ходе миграции, и корректной их загрузки.

Схема миграции стороны ДО2 (Выгрузка)

Основные этапы миграции на стороне ДО2:

1. Нормализация данных — предварительная обработка некоторых объектов базы для облегчения процесса миграции.
2. Настройка миграции:
   1. Выбор типов объектов для выгрузки, приоритета и порции их обработки.
   2. Выбор каталога выгрузки файлов.
3. Старт миграции:

   1. Формируется файл Start.txt — содержащий сведения о версии ДО2 и общий объем данных к загрузке. В этот файл далее будет «подсматривать» база ДО3 во время загрузки, чтобы определить все ли данные обработаны.

      

   2. Включается регламентное задание «Миграция. Выгрузка».
4. Процесс миграции (регламентное задание «Миграция. Выгрузка») — самый продолжительный этап:
   1. Последовательно выгружаются в файлы:
      1. История.
      2. Дельты — для их отслеживания и формирования используется подсистема «Отметки времени», о ней ниже.
   2. Во время выгрузки обновляются данные в файле Start.txt об общем объеме к загрузке.
5. Подготовка завершения миграции:
   1. Остановка работы пользователей.
   2. «Дообработка» и выгрузка последних дельт.
6. Завершение миграции — миграция завершается в ручном режиме после успешной загрузки всех исторических данных и данных об изменениях:

   1. Формируется файл Finish.txt с флагом = 1, служащим индикатором завершения миграции для системы ДО3.

      

   2. В случае преждевременного завершения, файл также сформируется, но будет установлен флаг = 0.

      

      Схема миграции, сторона ДО2

Схема миграции стороны ДО3 (Загрузка)

Основные этапы миграции на стороне ДО3:

1. Предварительная настройка:
   1. Выбор каталога выгрузки файлов.
2. Старт миграции:
   1. Стартует регламентное задание «Миграция. Загрузка».
3. Процесс миграции (регламентное задание «Миграция. Загрузка»):
   1. Последовательная загрузка файлов сообщений:
      1. Сначала файлы Истории.
      2. После файлы Дельт — для проверки актуальности загружаемых объектов используется подсистема «Отметки времени».
   2. Если объект не удалось записать, он фиксируется в очереди постобработки. Регламентное задание «Обработка очереди постобработки» проходит по этой очереди и делает несколько попыток записать объект.
   3. Удаление обработанных файлов.
4. Расчет прогресса: на основании общего количества к загрузке из файла «Start» и количества загруженных объектов производится расчет прогресса. 100% устанавливается только после появления файла Finish.
5. Завершение миграции: миграция завершается вручную, командой, которая разблокирует объекты системы для редактирования. Перед этим необходимо удостовериться, что все данные успешно загрузились:
   1. Проверить в ДО2, что нет записей отметок времени старше константы «ПереходГраницаИзменений», и что очередь отметок пуста.

   2. Проверить что в каталоге выгрузки пусто.

      

      Схема миграции, сторона ДО3

Мы уже несколько раз упомянули подсистему «Отметки времени», разберемся получше, что это такое и как она работает. И попробуем ответить на вопрос, насколько необходимо её использование.

Подсистема «Отметки времени»

Итак, если в общих словах, подсистема «Отметки времени» фиксирует «Отметку» — моменты времени изменения или выгрузки объектов системы, и позволяет выстроить эти моменты в некую очередь на временной шкале. Отметка формируется в виде числового значения текущей даты в миллисекундах. В первую очередь данная подсистема нужна для предотвращения возможных коллизий, которые могут произойти при выгрузке Дельт.

Подсистема присутствует в обеих версиях Документооборота и используется в передающей и в принимающей базах, но с несколько различающейся логикой:

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

Схема работы

Работу подсистемы можно разделить на три этапа — формирование промежуточной очереди отметок времени, формирование регистров отметок и дальнейшее их использование.

1. Сначала формируется «очередь отметок времени» — в момент изменения (ДО2) или загрузки (ДО3) ссылочных объектов и независимых регистров сведений срабатывают специальные подписки на события, которые фиксируют Отметку этого события в промежуточную очередь отметок времени состоящую из трёх одинаковых регистров сведений.
2. Далее формируется основной «список отметок» — регламентное задание «Обработка очереди отметок времени» распределяет записи очереди в конечные регистры сведений отметок, соответствующие типу объекта изменений отметок:
   1. ОтметкиВремениСсылочныхОбъектов;
   2. ОтметкиВремениРегистровПодчиненных;
   3. ОтметкиВремениРегистровНезависимых.

3. Дальнейшее использование «списка отметок» зависит от того, в какой базе мы находимся — выгружающей ДО2 или загружающей ДО3 (об этом ниже).

   

   Общая схема подсистемы отметок времени

Формирование очередей отметок времени

Подписки на события ПриЗаписи/ПередУдалением фиксируют Отметку изменения/загрузки объекта в один из трёх регистров сведений, имеющих одинаковую структуру полей:

• ОтметкаВремениОчередь1;
• ОтметкаВремениОчередь2;
• ОтметкаВремениОчередь3.

Ключевые поля регистров:

• Отметка — собственно отметка времени в миллисекундах.
• Ключ — ЛюбаяСсылка, хранит основной разрез, и определяется по-разному в зависимости от типа объекта:
• Для ссылочных объектов — ссылка на сам объект.
• Для подчиненных регистров — ссылка на регистратор.

• Для независимые регистров сведений — специально сгенерированная ссылка на несуществующий элемент справочника «Идентификаторы объектов метаданных». Причем уникальный идентификатор этой ссылки формируется хитрым способом из хеша MD5 полученного из представления отбора измерений регистра.

  

  При этом сами значения отбора также сохраняются отдельно в реквизите ЗначениеКлюча.

• Объект — ссылка на элемент справочника «Идентификаторы объектов метаданных» соответствующий виду объекта.

  

  Схема фиксации ключевых полей для различных типов объектов

Другие поля:

• ИдентификаторКлюча — судя по всему уникальный идентификатор полученный из Ключа.
• Удаление — признак того, что текущее событие является удалением объекта.
• ЗначениеКлюча — здесь хранится отбор для независимых регистров сведений.
• ТипКлюча — похоже внутренний признак разделения видов объектов, имеет тип «число». По нашим наблюдениям значение 0 соответствует — ссылочным объектам, 1 — подчиненным регистрам, 2 и 3 — независимым регистрам, возможно, есть и другие значения.
• Владелец/Источник — к сожалению, подробностей нет, в наших экспериментах они были заполнены пустыми ссылками на справочники «Учетные записи электронной почты» и «Идентификаторы объектов метаданных».

Равномерное распределение по регистрам

Что интересно, система стремится распределить поток записей между регистрами равномерно. Для этого она в каждом случае определяет нужный регистр, вычисляя его номер по следующему алгоритму — берется остаток от деления номера соединения ИБ на 3:

Тем самым на выходе получаем N от 1 до 3, для имени регистра «ОтметкаВремениОчередьN».

Судя по всему такая схема реализована для увеличения параллельности работы, чтобы один единственный регистр не стал «бутылочным горлышком» системы.

Формирование регистров отметок времени

Далее указанные регистры очередей обрабатываются регламентным заданием «ОтметкиВремениОбработка», которое распределяет записи очереди по конечным трём регистрам отметок, классифицируя их по типу метаданных объекта:

• ОтметкиВремениСсылочныхОбъектов — для ссылочных объектов.
• ОтметкиВремениРегистровПодчиненных — для подчиненных регистратору регистров.
• ОтметкиВремениРегистровНезависимых — для независимых регистров сведений.

По большей части поля такие же как в регистрах очередей, но есть отличия:

1. Во всех регистрах «Отметка» переместилась в ресурсы, её место в измерениях заняло поле «Граница» — по нашим наблюдениям тип и значение у них одинаковы.
2. В регистрах ОтметкиВремениСсылочныхОбъектов и ОтметкиВремениРегистровПодчиненных — отсутствует поле «ЗначениеКлюча» за ненадобностью.
3. В регистре ОтметкиВремениРегистровНезависимых измерение «Ключ» теперь хранит уникальный идентификатор ключа, а сама ссылка переехала в реквизит «КлючСсылка».

При этом при обработке очереди в целевой регистр отметок записывается только запись с максимальной Отметкой времени для каждого объекта. Например:

• Очередь содержит две записи об изменении одного и того же ссылочного объекта:
• Отметка: 63 888 855 397 155, время: 23.07.2025 8:16:37.
• Отметка: 63 888 855 404 204, время: 23.07.2025 8:16:44.
• После обработки в регистре сведений «Отметки времени ссылочных объектов» будет сохранена только запись с максимальной отметкой времени:
• Отметка: 63 888 855 404 204, время: 23.07.2025 8:16:44.

Обработка отметок времени

В конечном итоге регистры отметок используются в механизмах выгрузки Дельт ДО2 и при контроле загрузки ДО3.

Выгрузка Дельт на стороне ДО2

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

Выгрузка Дельт производится в рамках регламентного задания «Миграция данных из внешних систем выгрузка», процесс выглядит так:

1. Из регистров отметок выбирается порция строк с отбором границы больше установленной границы в константе «Переход. Граница изменений».
2. Далее объекты из этой порции выгружаются в файлы, и в них же записывается отметка времени, но уже не момента изменения, а фиксирующая момент выгрузки.
3. Происходит сдвиг границы в константе «Переход. Граница изменений» согласно максимальной границы выгруженных дельт.

Этапы пп.1–3 повторяются, пока не выберутся все записи из регистров отметок. После этого процесс завершается и ожидает следующего запуска регламентного задания «Миграция данных из внешних систем выгрузка».

Контроль изменений на стороне ДО3

Подсистема отметок времени на стороне ДО3 предназначена для предотвращения загрузки устаревших объектов.

1. Как уже описано выше, в процессе выгрузки данных из системы ДО2 в файле для каждого объекта присваивается Отметка, отражающая точное время выгрузки.
2. При загрузке в систему ДО3 эта Отметка из файла сопоставляется с максимальной Отметкой, зафиксированной для этого объекта в регистрах Отметок времени (включая регистры очередей):
   1. Если Отметка в файле больше максимальной, зарегистрированной в ДО3 — объект успешно конвертируется в формат ДО3, записывается в базу данных, и в журнале миграции создается запись о событии «Загрузка» с признаком «Принято».

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

      

      Пример коллизии из журнала миграции

      

      Проверка изменений при загрузке в ДО3

Почему нужна проверка изменений при загрузке на стороне ДО3

А так ли нужна эта подсистема отметок времени?

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

Многопоточная загрузка

Данная схема описывает сценарий, в котором подсистема отметок времени ДО3 предотвращает загрузку устаревшей версии объекта. Ситуация развивается следующим образом:

1. Изменения одного и того же объекта выгружены последовательно в файлы «Изменение 1» и «Изменение 2».
2. Загрузка файлов производится многопоточно двумя параллельными потоками.
3. Поток загрузки 2 раньше загружает изменение из файла «Изменение 002», которое является последним и актуальным.
4. Далее поток загрузки 1 попытается записать уже устаревшие изменения из файла «001». Подсистема отметок времени не позволит этого сделать.

Нештатное завершение потока загрузки

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

1. Поток загрузки 1 завершился аварийно и не успел записать изменение объекта, файл не удаляется, так как обработка прервалась аварийно.
2. Поток загрузки 2 успешно записывает изменения объекта из файла Изменение 002, которое является последним и актуальным. После загрузки файл удаляется.
3. И перезапущенный поток 1, как и в предыдущем случае попробует записать уже устаревшую версию. Аналогично подсистема Отметок времени запретит это действие.

Человеческий фактор

Рассмотрим еще случай, где возможна загрузка устаревшего объекта при ручной выгрузке/загрузке параллельно с регламентным заданием «Миграция. Загрузка»:

1. Пользователь выгружает внешней обработкой данные объекта в файл в 08:01.
2. После выгрузки происходит изменение объекта в 08:03.
3. Регламентным заданием миграции выгрузка на стороне ДО2 выгружает изменение объекта в 08:05.
4. Регламентным заданием миграции загрузка на стороне ДО3 загружает изменение в 08:09.
5. Пользователь пытается загрузить внешней обработкой ранее выгруженный файл, который на текущий момент уже является устаревшим.

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

Выводы

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

Полагаем, в теории, эту подсистему можно было бы отключить, при условии что:

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

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

Исходное положение дел в ДО2 перед миграцией

От общей схемы миграции перейдем к нашему опыту работы с ней.

Ниже приводится описание исходного состояния системы ДО2, зафиксированного перед началом процесса миграции в ДО3:

• Версия платформы 1С: 8.3.25.1336.
• Версии конфигураций 1С:Документооборот 8 — 2.1.32.6 и 3.0.10.20, обе в КОРП исполнении.
• Размер базы — 74 ГБ, при этом хранение файлов — на диске в томах.
• Общее количество записей на перенос — 27 468 012.
• Помеченные на удаление до начала миграции — 251 543.
• Действующие/недействующие пользователи: 5315 / 11557.
• Новых документов в день: ~ 650 в среднем.

Также стоит упомянуть, что в связке с ДО2 настроена бесшовная интеграция с базой на основе конфигурации ERP версии 2.5.17.162, с которой происходит активный обмен документами и двигаются бизнес-процессы.

Окружение

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

• Процессор: Intel Xeon Gold 6248R 3.00 ГГц (44 ядра).
• Оперативная память: 288 ГБ.

Сервер базы данных развернут на базе Microsoft SQL Server 2019 и имеет следующую конфигурацию:

• Процессор: Intel Xeon Gold 6248R 3.00 ГГц (44 ядра).
• Оперативная память: 812 ГБ.

Выше представлены характеристики виртуальных серверов. Используется виртуализация VMWare vSphere Client version 7.0.1.00200. Для общесистемного мониторинга используется Zabbix. На серверах СУБД и 1С используется ОС Windows.

В каком состоянии может находиться база

Как подступиться к задаче миграции? Считаем, что перед переносом данных в ДО3 необходимо провести оценку состояния базы данных. Ряд вещей в исходной базе могут повлиять на длительность процесса миграции или привести к ошибкам.

Сначала обозначим возможные «точки интереса», и далее по тексту опишем, что можно с этим сделать.

Итак, на что стоит обратить внимание:

1. Большое количество помеченных на удаление объектов:
• Желательно провести их обработку и максимально сократить количество ненужных объектов, ведь весь этот «балласт» переедет в ДО3, и при том сама миграция займет дополнительное время.
2. Большое количество незавершенных бизнес-процессов:
   • Главное здесь то, что процессы из ДО2 в ДО3 переезжают невозможными к маршрутизации, и каких то штатных средств для их продолжения не предусмотрено. То есть активные задачи на сторону ДО3 мигрируют, но продвинуть их далее по этапам бизнес процесса там не получится.
3. Незаполненное поле «Физическое лицо» в справочнике «Пользователи»:
• В ДО2 данный реквизит не имел решающего значения, при этом в ДО3 его использование стало более явным и контролируемым, ряд алгоритмов жестко завязаны на это соответствие и могут сломаться при таком положении дел.
4. Неработающее задание «Извлечение текста» и большое количество записей в справочнике «Версии файлов» со статусом извлечения текста «Не извлечен»:
   • Может привести к избыточной генерации записей дельт.

Теперь рассмотрим каждый пункт подробнее.

Действия по нормализации данных перед миграцией

Очистка помеченных на удаление объектов

Для начала стоит оценить общее количество объектов помеченных на удаление. Сделать это можно штатными средствами в стандартной обработке «Удаление помеченных объектов», которую можно найти в «Функциях для  технического специалиста».

В ней, если нажать кнопку «Выборочное удаление...», выбрать метаданные и нажать кнопку «Далее», то выведется статистика по разным объектам системы.

Там же при нажатии «Удалить» можно попытаться удалить помеченные объекты.

Свой инструмент

Увы, в нашем случае таких объектов было достаточно много – порядка 250 тысяч, и штатные средства отрабатывали бесконечно долго. Поэтому мы приняли решение о разработке собственного инструмента, который работал бы на основе типовых методов, но с парой оптимизаций. Ключевая идея тут – добавление очереди обрабатываемых объектов. С помощью неё появилась возможность отслеживать попытки удаления, и обрабатывать объекты определенными порциями, в том числе многопоточно.

Схема работы механизма:

Первым этапом выполняется Заполнение очереди.

Перед запуском выбираем количество потоков и размер порции ссылок:

Алгоритм заполнения очереди реализован на основе встроенной функции НайтиПомеченныеНаУдаление(), после её выполнения результат в несколько потоков записывается в очередь.

// Заполняет очередь помеченными объектами многопоточно 

// 

Процедура ЗаполнитьОчередьМногопоточноНаСервере() 

    

    Начало = ТекущаяДатаСеанса(); 

        

    Помеченные = НайтиПомеченныеНаУдаление(); 

    

    Порция = Новый Массив; 

    ДанныеКоличество = Помеченные.Количество(); 

    КоличествоПомеченных = ДанныеКоличество; 

    Размер = ДанныеКоличество / КоличествоПотов; 

    ПорцияРазмер = ?(Размер = Цел(Размер), Размер, Цел(Размер) + 1); 

    

    Для Каждого Элемент Из Помеченные Цикл 

           Порция.Добавить(Элемент); 

           

           Если Порция.Количество() = ПорцияРазмер Тогда   

               ЗапускФоновогоЗаданияОчередьПомеченныеЗаполнить(Порция); 

               Порция = Новый Массив; 

           КонецЕсли; 

    КонецЦикла;   

    

    Если Порция.Количество() Тогда 

           ЗапускФоновогоЗаданияОчередьПомеченныеЗаполнить(Порция);   

    КонецЕсли; 

               

КонецПроцедуры 

Сама Очередь представляет собой регистр сведений «del_ОчередьУдаленияОбъектов» в расширении:

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

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

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

// Очищает объекты 

// 

// Параметры: 

// Порция - ТаблицаЗначений - Порция 

// 

Процедура ОбъектыУдалить(Порция) Экспорт 

    

    КоллекцияКУдалению = Новый Массив; 

    Для каждого Состав Из Порция Цикл 

         КоллекцияКУдалению.Добавить(Состав.Ссылка);     

    КонецЦикла; 

    

    АдресХранилищаРезультата = ПоместитьВоВременноеХранилище(Неопределено, Новый УникальныйИдентификатор);   

    УдалениеОбъектов.УдалитьПомеченныеОбъекты(КоллекцияКУдалению, Неопределено, Неопределено, АдресХранилищаРезультата); 

    

    Результат = ПолучитьИзВременногоХранилища(АдресХранилищаРезультата); 

        

    Если Не ЗначениеЗаполнено(Результат) Тогда 

        Для каждого Строка Из Порция Цикл 

             ПараметрыРезультата = Новый Структура; 

             ПараметрыРезультата.Вставить("Ссылка", Строка.Ссылка); 

             ПараметрыРезультата.Вставить("Обработан", Истина); 

             ПараметрыРезультата.Вставить("Ошибка", Истина); 

             ПараметрыРезультата.Вставить("Комментарий", "Не удалось получить результат обработки удаления, обратитесь к разработчикам"); 

             ПараметрыРезультата.Вставить("ПрепятствуетУдалениюНепосредственно", Неопределено); 

             РезультатОчередьЗаписать(ПараметрыРезультата); 

        КонецЦикла;   

        Возврат; 

    КонецЕсли; 

    

    Если Не Результат.Статус Тогда 

        СообщениеОбОшибке = Результат.Значение; 

        Для каждого Строка Из Порция Цикл 

             ПараметрыРезультата = Новый Структура; 

             ПараметрыРезультата.Вставить("Ссылка", Строка.Ссылка); 

             ПараметрыРезультата.Вставить("Обработан", Истина); 

             ПараметрыРезультата.Вставить("Ошибка", Истина); 

             ПараметрыРезультата.Вставить("Комментарий", СообщениеОбОшибке); 

             ПараметрыРезультата.Вставить("ПрепятствуетУдалениюНепосредственно", Неопределено); 

             РезультатОчередьЗаписать(ПараметрыРезультата); 

        КонецЦикла;   

        Возврат; 

    КонецЕсли; 

    

    Если ТипЗнч(Результат.Значение) <> Тип("Структура") Тогда 

        Для каждого Строка Из Порция Цикл 

             ПараметрыРезультата = Новый Структура; 

             ПараметрыРезультата.Вставить("Ссылка", Строка.Ссылка); 

             ПараметрыРезультата.Вставить("Обработан", Истина); 

             ПараметрыРезультата.Вставить("Ошибка", Истина); 

             ПараметрыРезультата.Вставить("Комментарий", "Не  инициализированная ошибка, обратитесь к разработчикам"); 

             ПараметрыРезультата.Вставить("ПрепятствуетУдалениюНепосредственно", Неопределено); 

             РезультатОчередьЗаписать(ПараметрыРезультата); 

        КонецЦикла; 

        Возврат; 

    КонецЕсли; 

    

    Если НЕ  Результат.Значение.Свойство("НеУдаленные") Тогда 

        Для каждого Строка Из Порция Цикл 

             ПараметрыРезультата = Новый Структура; 

             ПараметрыРезультата.Вставить("Ссылка", Строка.Ссылка); 

             ПараметрыРезультата.Вставить("Обработан", Истина); 

             ПараметрыРезультата.Вставить("Ошибка", Истина); 

             ПараметрыРезультата.Вставить("Комментарий", "Не удалось  инициализировать неудаленные элементы, обратитесь к разработчикам"); 

             ПараметрыРезультата.Вставить("ПрепятствуетУдалениюНепосредственно", Неопределено); 

             РезультатОчередьЗаписать(ПараметрыРезультата); 

        КонецЦикла; 

        Возврат; 

    КонецЕсли; 

    

    Если НЕ  Результат.Значение.Свойство("Найденные") Тогда 

        Для каждого Строка Из Порция Цикл 

             ПараметрыРезультата = Новый Структура; 

             ПараметрыРезультата.Вставить("Ссылка", Строка.Ссылка); 

             ПараметрыРезультата.Вставить("Обработан", Истина); 

             ПараметрыРезультата.Вставить("Ошибка", Истина); 

             ПараметрыРезультата.Вставить("Комментарий", "Не удалось  инициализировать таблицу блокирующих ссылок, обратитесь к разработчикам"); 

             ПараметрыРезультата.Вставить("ПрепятствуетУдалениюНепосредственно", Неопределено); 

             РезультатОчередьЗаписать(ПараметрыРезультата); 

        КонецЦикла; 

        Возврат; 

    КонецЕсли; 

    

    Для каждого Элемент Из  Результат.Значение.НеУдаленные Цикл 

        ПараметрыОтбора = Новый Структура("Ссылка", Элемент); 

        Блокирующие =  Результат.Значение.Найденные.НайтиСтроки(ПараметрыОтбора); 

        Для Каждого Строка Из Блокирующие Цикл 

             ПараметрыРезультата = Новый Структура; 

             ПараметрыРезультата.Вставить("Ссылка", Строка.Ссылка); 

             ПараметрыРезультата.Вставить("Обработан", Истина); 

             ПараметрыРезультата.Вставить("Ошибка", Истина); 

             ПараметрыРезультата.Вставить("Комментарий", ?(Строка.ПрепятствуетУдалениюНепосредственно, "Непосредсвенная  блокировка к удалению", Строка.ТекстОшибки)); 

             ПараметрыРезультата.Вставить("ПрепятствуетУдалениюНепосредственно", Строка.Данные); 

             РезультатОчередьЗаписать(ПараметрыРезультата); 

        КонецЦикла; 

    КонецЦикла; 

    

    // Очистим удаленные 

    ОчередьЭлементыКОчистке = ОбщегоНазначенияКлиентСервер.РазностьМассивов(КоллекцияКУдалению,  Результат.Значение.НеУдаленные); 

    Для каждого Элемент Из ОчередьЭлементыКОчистке Цикл 

         ОчередьЗаписьУдалить(Новый Структура("Ссылка", Элемент));   

    КонецЦикла; 

        

КонецПроцедуры // ОчисткаПомеченных 

В нашем случае общее время удаления помеченных объектов составило одну неделю. По итогу из исходных 250 тысяч осталось не более 2 тысяч записей, которые признали неудаляемыми и перенесли их в ДО3 как есть.

Завершение неактуальных процессов

Теперь поговорим про бизнес-процессы. Сами по себе они участвуют в миграции и успешно переезжают на сторону ДО3, но как указано на ИТС в разделе «Новое в версии 2.1.32 — Миграция процессов» (its.1c.ru/db/updinfo#content:1361:hdoc:issogl2_15):

По сути это означает, что бизнес процессы запущенные в ДО2 не будет возможности продолжить на стороне ДО3, они там будут чисто для информации. Из этого следует, что по-хорошему перед окончанием миграции такие процессы необходимо завершить на стороне ДО2.

Для начала, чтобы решить какие действия следует предпринять, имеет смысл проанализировать незавершенные процессы. Сделать это можно с помощью отчета «Процессы» (e1cib/app/Отчет.ОтчетПоБизнесПроцессам?vrn=ТекущиеБизнесПроцессы):

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

Однако в базе также могут быть устаревшие или неактуальные процессы, которые однозначно следует завершить, например, в нашем случае это были:

• Дубли — по ряду причин в базе существовали задвоенные задачи, одни из которых уже выполнены, а вторые так и остались «висеть» незавершенными.
• Процессы вида «на ознакомление» — многие пользователи игнорируют подобные задачи, и они остаются в системе необработанными.

Их было решено завершить штатными средствами с помощью процесса эскалации.

Как правило этот механизм используется как некий помощник маршрутизации задач, например, если нужно настроить перенос просроченных задач на другого сотрудника или для автозавершения процесса «Ознакомление».

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

Как это сделать:

1. По результату отчета «Процессы» следует для себя выделить признаки неактуальности процесса. К примеру, это может быть превышение срока просроченности задачи или в целом устаревшая дата создания.
2. Далее создаем новый элемент в справочнике «Правила эскалации задач» (e1cib/list/Справочник.ПравилаЭскалацииЗадач):
   1. На вкладке «Правила эскалации» указываем:
      • «Что делать» — Выполнять автоматически.
      • «С результатом» — мы выбрали «Отрицательным».

      • «Для задач которые» — мы указали требуемый срок просроченности задач, также в этом параметре, например, можно выбрать срок невыполнения:

        

   2. На вкладке «Для процессов» указываем требуемый вид процесса по шаблону:

      

   3. На вкладке «Дополнительные условия» можно указать отборы по реквизитам в режиме СКД. Например, мы указали отбор по дате создания предмета:

      

3. Далее включаем регламентное задание «Эскалация задач» — данный регламент постепенно обработает все задачи подходящие под созданное правило.
4. Ход работы регламента можно отслеживать следующими отчетами:

   1. В форме правила эскалации по команде «Эскалированные задачи» в открывшейся форме нажимаем команду «Отчеты». Откроется форма со списком отчетов по эскалации:

      

      

      Эскалированные задачи
   2. Или всё в том же отчете «Процессы», с помощью отборов выводим не завершенные задачи, для мониторинга общего хода прогресса.

Сопоставление пользователей

Следующий момент, который стоит проверить в базе ДО2 перед миграцией — корректно ли заполнено поле «Физическое лицо» в справочнике «Пользователи».

Как указано в статье на ИТС (its.1c.ru/db/updinfo#content:1361:hdoc:issogl2_16):

Как нам известно, в ДО2 на реквизит «Физическое лицо» существенных механизмов не завязано, и при этом нет специализированных проверок на его заполненность. Из чего может сложиться ситуация, что в существенной части пользователей физлица не заполнены, при том, что сами физлица для этих пользователей в справочнике физлиц присутствуют.

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

В ДО3 по сравнению с ДО2 был расширен данный учетный блок справочником «Сотрудники». Все эти справочники — «Пользователи», «Физические лица», «Сотрудники» теперь стали связаны определенным способом. И реквизит «Физическое лицо» пользователя теперь участвует в ряде процессов из-за чего требования к качеству его заполнения возросли.

Миграция в таком состоянии может привести на стороне ДО3 к следующим проблемам:

• Дублированию физических лиц — в случае, когда физлицо существует, но не указано в пользователе, при загрузке будет автоматически создано новое с точно таким же наименованием.

• Некорректной установке адресных реквизитов — в случае использования общего физлица для нескольких Пользователей. Это обусловлено тем, что в регистре «Основные сотрудники» для каждого «Физического лица» может быть установлен только один сотрудник (измерение «Физическое лицо», ресурс «Сотрудник»). При записи нового сотрудника, он замещает предыдущего, делая его основным.

  Например: задача бизнес-процесса выполняется сотрудником Ивановым, у которого указано «Физическое лицо не определено». При установке фактического исполнителя используется параметр сеанса «Основной сотрудник», который определяется по «Физическому лицу» текущего сотрудника из регистра «Основные сотрудники». Если последним записанным сотрудником с тем же «Физическим лицом» был Петров, то фактическим исполнителем будет назначен Петров.

Логичный вывод в этой ситуации — заранее обработать такие элементы справочника Пользователи, сопоставить их с релевантным физическим лицом.

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

Как пример условия — пакет запроса, в котором сопоставление идет просто по наименованию элементов:

В конечном итоге после обработки из 5 тысяч пользователей 4 тысячи сопоставились с физическими лицами, осталось около 1 тысячи пользователей, для которых уже при миграции штатным методом создались физлица.

Обработка извлечения текста регламентным заданием

И последний в нашем списке момент связан с регламентом «Извлечение текста».

Обычно данное регламентное задание используется для получения текста из содержимого файла и записывает его в специальный реквизит, по которому далее появляется возможность проводить полнотекстовый поиск. В целом, это стандартный механизм конфигурации 1С:Документооборот, необходимый для поиска по содержимому файлов, не приводящий к каким-либо проблемам.

Но в нашей практике мы столкнулись со следующей ситуацией:

1. Регламентное задание «Извлечение текста» в наблюдаемой базе было долгое время отключено, так как у заказчика необходимости в полнотекстовом поиске не было. Соответственно, в базе накопилось огромное количество версий файлов со статусом «Не извлечен».
2. После чего во время одной из тестовых миграций, при нажатии в форме миграции на кнопку «Включить рег. задания», задание «Извлечение текста» неявно стартовало и начало обрабатывать все накопленные версии файлов.

В итоге у нас во время миграции это привело к резкому скачку формируемых Дельт и очереди отметок времени. Среднее количество Дельт в сутки выросло с ~55 тысяч до ~900 тысяч, в результате чего миграция сильно замедлилась. Естественно, как только обнаружили источник, регламент выключили.

Что тут можно посоветовать: проверить включен ли у вас регламент «Извлечение текста». А также оценить количество версий файлов к обработке (к примеру, у нас их было несколько миллионов). Для этого можно, например, использовать следующий запрос, который применяется как раз в методе регламентного задания:

ВЫБРАТЬ
  КОЛИЧЕСТВО(1) КАК Количество
ИЗ
  Справочник.ВерсииФайлов КАК Т
ГДЕ
  (Т.СтатусИзвлеченияТекста = ЗНАЧЕНИЕ(Перечисление.СтатусыИзвлеченияТекстаФайлов.НеИзвлечен)
      ИЛИ Т.СтатусИзвлеченияТекста = ЗНАЧЕНИЕ(Перечисление.СтатусыИзвлеченияТекстаФайлов.ПустаяСсылка))
  И НЕ Т.Зашифрован
  И НЕ ТИПЗНАЧЕНИЯ(Т.Владелец.ВладелецФайла) = ТИП(Справочник.СерверныеСообщенияСВД)
  И НЕ ТИПЗНАЧЕНИЯ(Т.Владелец.ВладелецФайла) = ТИП(Документ.ВходящееСообщениеСВД)
  И НЕ ТИПЗНАЧЕНИЯ(Т.Владелец.ВладелецФайла) = ТИП(Документ.ИсходящееСообщениеСВД)

Если у вас похожая ситуация на нашу, то дальше полагаем главное ответить на вопрос «Нужен ли полнотекстовый поиск по содержимому файлов?».

Если он не нужен, то достаточно предупредить включение регламента «Извлечение текста», то есть сразу после нажатия «Вкл. все регламенты» отключить его. Про этот этап мы расскажем ниже по тексту стати.

Если же полнотекстовый поиск нужен, тогда конечно странно, что регламент извлечения был выключен. Но раз мы уже находимся в этой ситуации, то лучше либо запустить его на стороне ДО2 и обработать большинство версий файлов до миграции, либо также предупредить его включение и запустить такой же регламент уже на стороне ДО3 после миграции.

Поддержание базы в нормализованном состоянии (в процессе миграции)

Мы рассказали как подготовили базу, а что делать по этим пунктам во время самой миграции?

• Очистка помеченных на удаление объектов:
• После старта миграции обработку помеченных на стороне ДО2 лучше отключить и продолжить уже в ДО3 после окончания. Лишние действия с помеченными объектами повлекут за собой увеличение очередей отметок и возникновение дельт, что в итоге увеличит время миграции.
• Завершение запущенных процессов:
• Перед завершением миграции следует повторно проверить активные бизнес-процессы и, по возможности, завершить описанным ранее способом.
• Создание новых пользователей:
• При создании новых пользователей обязательно сопоставлять с релевантным физическим лицом, этот вопрос можно решить либо управленческим решением, либо введя дополнительные программные условия при записи пользователя на ваш выбор.
• Извлечение текста:
• Следуем выбранным курсом, то есть либо отключаем задание «Извлечение текста», либо нет.

Приступаем к миграции

Мы поговорили про устройство миграции и подготовку базы ДО2 к миграции. Теперь перейдем к описанию конкретных настроек и действий при старте, во время процесса и при завершении миграции.

Настройки на стороне ДО2

Чтобы стартовать миграцию, выполним следующие действия

1. Включение опций — в подсистеме «Настройка и администрирование» выбираем «Настройка программы» → «Обмен данными»:

Устанавливаем следующие флаги и нажимаем «Сохранить настройки»:

• «Использовать отметки времени» — отвечает за активацию подсистемы «Отметок времени».
• «Миграция данных в новую версию» — этот флаг дает доступ к обработке «Миграция на новую версию», знаменует факт того, что система готовится к миграции. Например, при включении флага заполняется специальный регистр сведений «Переход. Объекты выгрузки» с настройками миграции метаданных.

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

Вкладка «Настройка»: указываем каталог выгрузки/загрузки данных. В него будут выгружаться файлы миграции — История/Дельты:

• Данный каталог должен быть доступен и со стороны ДО2 и со стороны ДО3.
• Также проверьте, что на диске достаточно свободного места.
  Примечание: сколько именно — сложно сказать. Но для грубой оценки может пригодиться наш пример — для базы размером 74 ГБ выгрузилось данных «Истории» на 97 Гб. Предполагаем, что разница обусловлена преобразованием типов и какой-то долей дополнительной сопроводительной информации в этих файлах.

Вкладка «Объекты» — здесь выводится список метаданных системы с различными настройками выгрузки. Например, тут можно задать размер порции данных — это отсечка по количеству объектов, при которой система будет создавать новый файл выгрузки. Также в этом списке выводится статистика по количеству выгруженных объектов, которая будет обновляться в течение процесса:

Вкладка «Журнал» : отображает зафиксированные события выгрузки данных после старта миграции. По нему можно отслеживать этапы миграции:

3. Выделение технологического окна (выгрузка Истории):

• Как уже говорилось, выгружаемые данные можно разделить на две части — Историю и Дельты, соответственно, первый этап — выгрузка Истории, то есть данных базы, существующих на момент начала миграции.
• Считаем, что этот этап необходимо проводить в период технологического окна с заблокированным входом для пользователей и отключенными регламентными заданиями. Для понимания длительности: в нашем случае выгрузка истории длилась ~6,5 часов.

4. Старт миграции:

Подготовка к старту — отключение регламентных заданий.

Перед стартом на время загрузки Истории следует выключить регламентные задания, это можно сделать в обработке миграции на вкладке Настройка по кнопке «Еще» — > «Отключить рег. задания»:

После этого в списке регламентных заданий должны остаться только следующие:

1. Миграция данных из внешних систем выгрузка — ключевое задание выполняющее выгрузку истории и изменения в файлы по заданным настройкам.
2. Отметки времени. Обработка — Обрабатывает очередь отметок времени, оно необходимо для последующей выгрузки Дельт.
3. Заполнение рабочих групп перехода — данный регламент необходим для корректного переноса прав доступа, он заполняет регистр сведений «Рабочие группы для перехода», для переноса прав доступа по-объектно для участников. К слову, в нашем случае пришлось его всё же выключить, так как особенности настройки прав в исходной базе в сочетании с большим количеством документов (~17 тысяч) привели к огромному количеству сочетаний участник-объект (11 миллиардов записей), из-за чего миграция практически остановилась. О том, как это происходило и как мы решили задачу подробно расскажем в следующей части статьи.

После всех приготовлений нажимаем кнопку «Начать»:

• В этот момент в корне настроенного каталога миграции появится файл Start с данными релиза и количеством записей Истории перед началом миграции, указанное количество в файле используется для расчета загруженных объектов в процентах на стороне ДО3.
• ВНИМАНИЕ: Отслеживайте размер базы в процессе миграции. После старта миграции начнут заполняться регистры подсистемы «Отметок времени» фиксируя изменения объектов, при этом, похоже, данные регистры не очищаются сами. Следовательно, размер базы ДО2 на время миграции будет увеличиваться быстрее, чем обычно. В нашем случае на начало миграции база была размером 74 ГБ, к концу процесса длительностью в 3 недели размер базы вырос до 115 ГБ.

5. Завершение выгрузки истории:

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

   Посмотреть на прогресс-бар, если дошел до 100%, значит вся История выгружена:

   

   Так как Дельты начинают выгружаться только после Истории, можно определить факт завершения выгрузки Истории по тому, что Дельты уже начали выгружаться.

   • В журнале миграции при сортировке по дате можно будет увидеть вместо события «Выгрузка История» события «Выгрузка Изменения»:

     

     Окончание выгрузки истории

   • Ещё можно обратить внимание на каталог выгрузки, если в подкаталогах начали появляться файлы с расширением tmp. Их наличие указывает на то, что выгрузка дельт началась. Расскажем о них подробнее ниже по тексту:

     

2. Конец технологического окна.

   После завершения выгрузки Истории можно «закрывать» технологическое окно, то есть впускать пользователей в базу. А также включать регламентные задания — это можно сделать на вкладке «Настройка» по кнопке «Еще» — > «Включить рег. задания»:

   

   Важно!

   Это команда работает следующим образом:

   • Ранее при отключении регламентных заданий система «запомнила», какие задания были включены, и теперь при нажатии «Включить рег. задания» она их активирует.
   • Но помимо этого вызывается метод
     УстановитьИспользованиеРегламентныхЗаданийПоФункциональнымОпциям из общего модуля РегламентныеЗаданияСлужебный, который может включить некоторые регламенты, которые были выключены до миграции. Именно так у нас стартовало задание «Извлечение текста», о чем мы писали в разделе о нормализации данных. Так что после нажатия кнопки имеет смысл проверить список регламентных заданий, не запустилось ли чего лишнего.

3. Бэкап каталога с историей.
   В целях сохранения возможности ретроспективного анализа загруженных данных, имеет смысл выполнить резервное копирование каталога, содержащего файлы выгрузки.

6. Следующий этап — «выгрузка Дельт», то есть выгрузка измененных объектов зарегистрированных в регистрах Отметок времени. Этап выполняется параллельно с работой пользователей и необходим для плавного перехода. Сколько времени он займет зависит от разных факторов, например, от количества появления новых изменений в базе и скорости миграции. На протяжении этого времени мы мониторим процесс миграции:

• Отметки времени — отслеживаем очереди отметок, они не должны расти, также смотрим на границу отметок, она должна двигаться и не сильно «запаздывать». Эти признаки могут указывать на то, что отметки не успевают обрабатываться, следует обратить на это внимание.
• И ожидаем появления предпосылок для завершения миграции, они описаны в пункте «Завершение миграции».

Настройки на стороне ДО3

Теперь рассмотрим порядок действий для старта миграции на принимающей стороне.

1. Включение опций: аналогично тому, как делали в ДО2, в подсистеме «Настройка» выбираем «Настройка программы» → «Обмен данными»:

Устанавливаем флаги и нажимаем «Сохранить настройки»:

• «Отметки времени» — отвечает за активацию подсистемы «Отметок времени».
• «Загружать данные из 1С Документооборот 2.1» — этот флаг активирует систему миграции, в частности, дает доступ к обработке «Миграция данных из предыдущей версии».

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

• Вкладка «Настройка»: здесь достаточно указать путь к каталогу с файлами выгрузки, то есть тот же, что был в настройках выгрузки ДО2.

  

  Вкладка «Настройка» ДО3

• Вкладка «Журнал» : как и в ДО2 отображает зафиксированные события загрузки данных миграции после начала работы основного регламентного задания «Миграция с предыдущей версии. Загрузка»:

  

  Вкладка «Журнал» ДО3

3. Подготовка к старту загрузки — зависит от того, подразумевается ли работа пользователей одновременно в двух базах. В нашем случае такой вариант не подходил заказчику, помимо этого мы полагаем, что подобный сценарий создаст дополнительную нагрузку на ДО3, что будет замедлять загрузку данных миграции. Поэтому в нашем случае было принято решение миграцию в ДО3 проводить в режиме технологического окна — с заблокированными пользователями и отключенными регламентами:

• Выключить регламентные задания, кроме необходимых, можно по кнопке на вкладке Настройка «Еще» → «Отключить рег. задания»:

  

  Отключение регламентных заданий

  Таким образом в списке регламентных заданий должны остаться только:

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

  • «Разбор очереди постобработки»: повторно обрабатывает объекты, которые не удалось обработать при обычной загрузке из-за ошибок. К примеру, это может быть ошибка записи объекта — объект № 1 не запишется из-за наличия в реквизитах битой ссылки на объект № 2 и попадет в очередь, далее объект № 2 придет по обмену и при повторной обработке из очереди объект № 1 уже успешно запишется и при успешной обработке запись из очереди удалится:

    

4. Старт миграции: загрузка запускается командой «Начать» на вкладке «Настройка». При нажатии система проводит автоматическую проверку совместимости текущей версии ДО3 с версией ДО2 используя файл «Start.txt», содержащий информацию о релизе ДО2.

• В случае успешного прохождения проверки, запускается процесс миграции, иначе не запустится с указанием ошибки совместимости релизов.

• После этого можно убедиться, что регламентное задание «Миграция с предыдущей версии. Загрузка» функционирует:

  

  Старт загрузки ДО3

5. Дальше мониторим ситуацию:

• Оцениваем состояние загрузки по прогресс бару и динамике количества обработанных объектов:

  

  «Осталось 174 дня?!» — не пугайтесь, картинка взята из тестовой базы. В нашем случае реальная миграция длилась около 3-х недель.
• Аналогично процессу выгрузки из ДО2 имеет смысл посматривать на очередь отметок времени, успевает ли она «разбираться».
• Следим за количеством файлов в каталоге выгрузки, так поймем успевает ли процесс загрузки в ДО3 за появлением новых изменений в ДО2.
• И ожидаем условий для завершения миграции — о них далее.

Завершение миграции

Мы стартовали миграцию со стороны ДО2 и инициировали загрузку со стороны ДО3. Теперь поговорим о том, как завершить этот процесс.

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

1. История загружена в ДО3 полностью — это условие необходимое, но не достаточное. Мы для себя выделяем его выполнение в отдельный этап. Правда, какой-то специальной индикации для этого нет, например, по прогресс бару этого понять нельзя — на стороне ДО3 он показывает общий прогресс загрузки Истории и Дельт. Но можно проверить следующими способами:

   • Один из признаков — если в журнале событий миграции в ДО3 начали появляться строки с флагом «Изменения», значит загрузка Истории завершена:

     

   • Также можно посмотреть в каталог выгрузки. Мы уже упоминали наличие tmp как признак старта выгрузки Дельт. Отсюда же можно сделать другой вывод — если там только tmp-файлы, это можно считать признаком, что история уже загрузилась:

     

2. Большая часть Дельт выгружена и загружена — это значит, что база ДО3 достаточно близка по наполнению к ДО2:

   • Для проверки степени выгруженности Дельт на стороне ДО2 можно проверить границу отметок — она должна быть близка к максимальной дате всех регистров отметок. Это означает, что очередь отметок отработана и на текущий момент невыгруженных Дельт нет:

     

   • Для проверки степени загруженности Дельт на стороне ДО3 можно:

     • Проверить прогресс бар, он должен быть близок в 99%. К слову значение в 100% не будет достигнуто пока мы не завершим миграцию.

       

     • Также можно проанализировать каталог выгрузки — по количеству и объему файлов можно косвенно понять сколько осталось загрузить. Если каталог пуст, соответственно, на текущий момент всё загружено.

3. Проверить очередь постобработки — на предмет, что она обрабатывается и в ней нет «зависших» объектов, то есть таких объектов, которые остались не обработаны. В этом случае следует сначала разобраться с этими ошибками и только после этого переходить к следующему этапу:

   

Как только мы достигли этих условий можно инициировать ещё одно технологическое окно для финализации миграции. Для примера, в нашем случае этот этап занял ~2 дня, при этом само завершение миграции со всеми проверками было выполнено за 2 часа, а в остальное время были проведены различные сопроводительные операции по переходу — пересчет прав, перенастройка миграции, тесты и т. д.

Этапы финализации:

1. Подготовка:
   • Блокируем вход пользователей.
   • Отключаем регламентные задания в обеих базах, кроме ключевых для миграции.
2. Завершение миграции в ДО2:
   • Ждем завершения выгрузки из ДО2 финальных Дельт. Так как мы запретили работу и регламенты, новых Дельт появляться не должно. Соответственно, как только граница отметок станет равна максимальной дате в регистрах отметок, считаем что финальные Дельты выгружены.

   • Нажимаем кнопку «Завершить» в обработке «Миграция на новую версию» на стороне ДО2:

     

   • В этот момент в каталоге выгрузки создается файл, который сигнализирует системе ДО3:

     

3. Завершение миграции в ДО3:
   • Аналогично на стороне ДО3 необходимо убедиться, что финальные Дельты загрузились. Как и прежде, надежный признак — это пустой каталог выгрузки и пустая очередь постобработки.

   • После этого нажимаем кнопку «Завершить» на стороне ДО3:

     

Поздравляем, миграция завершена!

Теперь можно приступить к перенастройке интеграции, пересчету прав и т. д. А также запускать счастливых пользователей в базу ДО3 осваивать новые возможности.

Пару слов о нюансах работы выгрузки и загрузки

Рассмотрим чуть подробнее некоторые моменты в работе регламентов выгрузки и загрузки.

Про «последовательность» объектов

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

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

Далее число последовательности попадает в наименование файла. Например, так может выглядеть файл выгрузки версий файлов — во второй части наименования файла после точки мы видим последовательность 500:

После этого файлы считываются уже на стороне ДО3 и порядок их загрузки определяется последовательностью как раз из наименования файла.

Про каталоги и файлы

Приведем ещё раз краткую схему выгрузки:

1. Данные базы (История) выгружаются регламентным заданием «Миграция данных из внешних систем выгрузка» порциями на основе настроек из регистра «Переход. Объекты выгрузки»:
   • При этом после каждой выгруженной порции записывается в регистр «Переход. Объекты выгрузки» количество выгруженных данных по типам объектов. Так же фиксируется информация о выгруженных данных в регистр сведений «Миграция данных из внешних систем журнал».

   • Файлы создаются в отдельных подкаталогах миграции разбиваясь по 1000 файлов в каждом подкаталоге, каталоги нумеруются начиная от 1. Формат файлов .json. При успешной загрузке в приемник файлы удаляются:

     

2. Данные изменений (Дельты) выгружаются на основе регистров отметок времени, после выгрузки изменений двигается граница в константе «Переход. Граница изменений» по максимальной отметке выгруженного объекта.
   Файлы Дельт создаются этапами:

   • Сначала в каталогах по тому же принципу что и для Истории создаются файлы, но формата не json, а tmp. Файлы эти не имеют содержимого, и являются, как их именуют в коде, «метками пакетов» — в имени файла записываются имена каталогов с файлами изменений:

     

   • Сами каталоги изменений находятся в папке с именем «0» корня миграции, они создаются с именами аналогичными в файлах .tmp:

     

   • И далее в созданные каталоги выгружаются уже файлы .json содержащие данные измененных объектов:

     

Про особенности работы регламента загрузки в ДО3

После старта миграции инициируется регламентное задание «Миграция с предыдущей версии. Загрузка». Данный регламент реализует схему многопоточной загрузки. Сам он ничего не загружает, а является своего рода управляющим по запуску дочерних фоновых заданий — потоков. Каждый раз при запуске регламентное задание миграции проверяет количество активных потоков загрузки:

1. Если их менее 5, тогда стартует новый поток. Это число зашито программно, в случае файловой базы поток может быть только один.
2. Каждый новый поток получает в обработку не более 2-х файлов из каталога загрузки. Количество файлов также зафиксировано в программе.
3. Причем запуск новых потоков зависит от последовательности указанной в файлах:
   • 3072.500.399912.0.1.ВерсииФайлов;
   • 7074.800.399912.0.1.Файлы;

   • 13077.900.399912.0.1.ВнутренниеДокументы.

     А туда, как мы уже выяснили, оно попадает из настроек «Объекты» из базы ДО2:

     

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

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

   

   Схема загрузки данных в ДО3

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

В каждой итерации работы регламента отслеживается, что запущен поток с таким признаком «первый поток». То есть из максимально активных 5-ти потоков должен быть один с таким признаком. Как только он завершается, регламент при запуске очередного потока присваивает ему тот же признак.

В виду этой особенности в нашей практике мы сталкивались с некоторыми проблемами:

1. Во-первых, Обработка очереди отметок времени может занимать существенное время и тогда в списке фоновых процессов мы будем лицезреть картину, когда 4 потока постоянно обновляются, а 1 как бы «висит» с самого начала загрузки. И далее может сложиться ситуация, при которой вся текущая последовательность обработана, но следующая не берется в работу, пока работает указанный «Первый поток».
2. Во-вторых, помимо потока, как мы уже рассказывали, эти очереди отметок обрабатываются отдельным регламентом, что в нашем случае приводило к ошибкам взаимоблокировок.

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

Этап пробной миграции

На нашем проекте перед тем как заняться миграцией на продуктиве мы начали с так называемой пробной миграции. Этот процесс включал в себя:

• Собственно миграцию — то есть выгрузку данных из копии рабочей базы данных ДО2, их последующую загрузку в целевую среду ДО3.
• Моделирование пользовательской активности в системах ДО2 и в интегрированных системах (ERP) в период выполнения миграции.
• Анализ перенесенных данных на предмет корректности и полноты.
• Тестовый запуск и оценка функционирования нового функционала ДО3.

Аргументация необходимости этапа

Для чего производим пробную миграцию?

Основная задача состоит в проверке механизмов миграции, идентификации проблемных зон и проверки процесса переноса данных в условиях, максимально приближенных к рабочей среде без риска что-то сломать. А также проверка того, как себя будет «чувствовать» база выгрузки ДО2, так как во время реальной миграции в ней будут продолжать работать пользователи.

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

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

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

Сбор тестового стенда

До начала миграции в распоряжении клиента имелся тестовый стенд по своим вычислительным ресурсам аналогичный рабочей среде. Точно такие же три центральных рабочих сервера:

• Процессор: Intel Xeon Gold 6248R 3.00 ГГц (44 ядра).
• Оперативная память: 288 ГБ.
• Версия платформы: 8.3.25.1336.

С сервером СУБД на MSSQL Server 2019:

• Процессор: Intel Xeon Gold 6248R 3.00 ГГц (44 ядра).
• Оперативная память: 812 ГБ.

На виртуализации VMWare vSphere Client version 7.0.1.00200.

Базы тестового стенда миграции

В самом стенде мы постарались привести схему компонентов к тому, как это устроено в рабочем сервере:

1. Развернули свежие копии рабочих баз 1С:ERP, 1С:ДО2.
2. Опубликовали web-сервисы и настроили интеграцию тестовой ДО2 в тестовой ERP.
3. Развернули пустую базу ДО3.

4. А также подключили 1С:ДО2 и 1С:ДО3 к тестовому тому хранения файлов. Данный тестовый том не повторяет рабочий том по наполнению, для нашей задачи это было не существенно, так как сами файлы в миграции не участвуют.

   

Организация пользователей-тестировщиков

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

• В базе ERP: проверка корректности функционирования объектов, интегрированных с 1С:ДО2, включая процессы создания, согласования и обмена документами, работу с файлами.
• В базе ДО2: проверка механизмов исполнения и маршрутизации задач, а также оценка стабильности функционирования интеграционных механизмов с ERP и успешность выгрузки как исторических, так и данных изменений для миграции.
• В базе ДО3: проверка целостности мигрированных исторических данных, так же загруженных данных изменений.

Результаты пробной миграции

Сама пробная миграция, увы, так и не была завершена до победного. Изначально заказчиком была озвучена комфортная длительность миграции в 2 недели. В итоге пробная миграция была прервана после 1-го месяца работы при достигнутом прогрессе в 80%. Несмотря на прерывание миграции по итогу в нашем распоряжении оказалась база ДО3 с реальными данными, которую уже можно было брать на вооружение для переноса доработанного функционала ДО2 и тестирования возможностей новой среды.

Но самое главное, по результату пробной миграции мы выявили ряд сложностей и «узких мест», над которыми предстояло поработать, например:

• Существенное замедление скорости загрузки на стороне ДО3 в процессе миграции данных ввиду особенностей запуска потоков и работы подсистемы отметок времени.
• Проблематика формирования огромного количества объектов «Рабочие группы для перехода».
• Проблема с отображением файлов в карточках документов.
• Мигрированные, но не завершенные активные процессы на стороне ДО3.
• И ещё ряд других.

Заключение

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

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

До скорых встреч!