Миграция данных из DIRECTUM 5 в Directum RX SQL. Перенос записей справочников и папок

В статье затронем тему миграции данных с D5 на DRX на СУБД MS SQL, расскажу про основные моменты конвертации, и про личный опыт на таких проектах.

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

Что нужно знать, чтобы начать:

1. Знание структуры баз данных D5 и DRX.
2. Знание СУБД MS SQL и Transact-SQL
3. Хотя бы начальные знания по SQL Server Integration Services (SSIS), что это и как работает.
4. Изучить документацию по конвертеру (идет в комплекте с конвертером).

Что потребуется для настройки и выполнения миграции:

1. Система Directum RX на MS SQL сервере со всей кастомной разработкой, если она необходима. Если миграция проходит из коробочной системы в коробочную систему, то нам же проще. Система должна быть без данных.
2. База данных источник DIRECTUM 5 (Бэкап продуктивной системы).
3. Visual Studio (я использую 2019 версию Community, ее вполне достаточно) + необходим  SQL Server Integration Services Projects для Visual Studio.
4. Актуальная версия конвертера D5 – DRX

Подготовка систем

DIRECTUM 5

1. Создать таблицы для конвертации выполнив скрипт \SQLScripts\MSSQL\ 01_CreateColumn_DIR5.sql
2. Если у пользователей более одного работника, то нужно их отвязать, чтобы в итоге получилось 1 пользователь 1 работник. Иначе возникают ошибки при переносе документов.
3. Проверить что заполнен реквизит «Подразделение» в ТКЭДах Входящих и Исходящих писем, по этому реквизиту вычисляется Наша организация и подразделение для заполнения в Directum RX
4. Проверить права на документы в D5, встречается такое что «все видят все», т.е любой пользователь поиском может найти все документы которые есть в системе потому что права по умолчанию выдаются на группу в которую входят практический все пользователи, при переносе в RX в реестрах получится мешанина из лишних документов которые пользователю не нужны. Если на документ есть "лишние" права их необходимо удалить, написав сценарии в D5 или сделать это вручную. 

Directum RX

1. Создать таблицы для конвертации выполнив скрипт \SQLScripts\MSSQL\ 02_CreateColumn_RX.sql
2. Создать служебного сотрудника в системе (его ИД понадобится дальше)
3. Создать необходимые ВЭДы так как из Д5 они не переносятся.

Все, система Directum RX развернута и подготовлена. БД D5 подготовлена для переноса данных. Перед началом конвертации рекомендую сделать бэкап БД Directum RX. Это нужно на случай, если что-то пойдет не так, и мы бы могли просто восстановить БД из бэкапа.

Запуск конвертора

Запускаем конвертер и видим контейнеры, в которых объединены задачи по переносу данных - рисунок 1.

Рисунок 1

Для начала необходимо сделать следующие настройки: внизу на панели диспетчера указать реквизиты подключения к нашим базам данных рисунок 2 и 3

Рисунок 2

Рисунок 3

После того как укажем реквизиты, у нас начнется проверка пакета. Обычно она проходит не дольше минуты, но пару раз натыкались на баг (видимо самой Visual Studio), что проверка идет бесконечно. Помогает только переустановка Visual Studio.

Вторым шагом необходимо заполнить переменные как на рисунках 4, 5.

Рисунок 4

Рисунок 5

Описание переменных:

DateLastRunDoc – Дата от которой берем документы для переноса (заполняется для доконвертации, если первичная конвертация, то оставляем как есть).

DateLastRunRef – Дата от которой берем записи справочников (заполняется для доконвертации, если первичная конвертация, то оставляем как есть).

DateLastRunTask – Дата от которой берем задачи (заполняется для доконвертации, если первичная конвертация, то оставляем как есть).

IsFirstMigration – Признак первичной миграции. По умолчанию true если доконвертация то false

RXServiceRecipientId – ИД служебного сотрудника, которого мы создали при настройке Directum RX.

Более подробная информация по переменным и настройке конвертации/доконвертации в документе «Directum RX. Конвертер данных Directum в Directum RX. Описание решения.pdf» - идет в комплекте с мигратором.

После настроек конвертера можно выполнять контейнер «Справочники и папки» - рисунок 6.

Рисунок 6

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

Если при переносе возникают ошибки, они будут отображаться на вкладке «Обработчик событии».

Идем дальше, миграция справочников прошла без ошибок.

У нас мигрировали все служебные справочники, орг.структура компании, папки.

После миграции

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

1. Проверяем корректность переноса орг.структуры.
2. Проверяем перенесенные роли.
3. Проверяем права на папки.
4. Пробуем создать записи в справочниках, и в табличных частях записей справочников.

Возможные ошибки:

1. «Нарушена уникальность свойств в таблице» - ошибка при сохранении новой записи. Если видим ее, то не паникуем (я ее как-то уже после конвертации, на продуктиве увидел). Идем в MSSMS, и выполняем запросы

Select

  *

from

  Sungero_System_Ids

where

  TableName = 'Sungero_Core_Link' --Имя нашей таблицы для проверки

select Max(id) from Sungero_Core_Link --Наша таблица

ИД в поле LastId не должно быть меньше чем максимальный ИД из таблицы Sungero_Core_Link. Если ИД в Sungero_System_Ids меньше чем максимальный в Sungero_Core_Link то выполняем запрос

update

  Sungero_System_Ids

set

  LastId = (select Max(id) from Sungero_Core_Link) --Наша таблица

where

  TableName = 'Sungero_Core_Link' --Имя нашей таблицы

           После выполнения запроса перезапускаем пулы и проверяем, ошибка должна исчезнуть

2. Возможна такая ситуация, что после переноса не заполнились реквизиты, которые ссылаются на другие записи. Если такая ситуация все-таки возникла, то идем в конвертер. Заходим в задачу переноса данных тех записей, которые не заполнились. И в назначении проверяем, соотнесены ли поля XRecID. Соотносим поля, откатываем RX в состояние «До переноса», очищаем таблицы с префиксом Convert_ в D5 и запускаем заново перенос справочников.

Пока это все, дальше в планах написать про перенос кастомных справочников и про перенос документов.