Перенос исторических данных БОСС-Референт - DIRECTUM. Как это было?

Введение

В данной статье рассматривается архитектура и описывается метод переноса исторических данных из системы БОСС-Референт (платформа Lotus Notes) в DIRECTUM.

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

Необходимо перенести исторические данные из системы БОСС-Референт за последние 2 года.

Список переносимых объектов:

Выполнить перенос данных необходимо за выходные. БОСС-Референт останавливается вечером в пятницу после рабочего дня и с утра понедельника пользователи уже работают в DIRECTUM.

Анализ

Данные в БОСС-Референт хранятся в виде «Документов» (карточка со структурированной информацией и прикреплённые к ней файлы).

Документы представлены различными формами (аналог Типов справочников и ТКЭД DIRECTUM).

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

База данных системы БОСС-Референт не реляционная, соответственно, единственным способом выгрузить данные является использование объектной модели Lotus.

Способов же загрузки данных в DIRECTUM рассматривалось 2:

1. Объектная модель (ОМ) DIRECTUM.
2. Прямые SQL-запросы.

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

Объектная модель (ОМ) DIRECTUM

«+» Простота разработки. 

«-» Низкая скорость.

Прямые SQL-запросы

«+» Высокая скорость переноса данных. 

«-» Необходимость предварительной выгрузки данных в БД на SQL.

«-» Риск нарушения целостности данных.

Учитывая следующие факторы:

• необходимость быстрого переноса данных;
• переносятся только данные справочников и ЭД.

Была выбрана следующая схема переноса данных.

Схема переноса данных

1. Данные из БОСС-Референт выгружаются в промежуточную БД MS SQL.
2. Данные в промежуточной БД конвертируются в формат DIRECTUM.
3. Сконвертированные данные переносятся в DIRECTUM с помощью Insert-запросов.

Выгрузка данных

Пара слов о том, что из себя представляла промежуточная БД.

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

Примеры:

-- Резолюции
Create table Resolutions 
(
 ID int IDENTITY NOT NULL ,				-- Служебное поле

 ResolutionID varchar(512) null,
 created DateTime null,
 DateFact DateTime null,
 DatePlan DateTime null,
 EXECUTORMAINID varchar(512) null,
 isControl varchar(512) null,
 PARENTDOCGROUPID varchar(512) null,
 PARENTDOCID varchar(512) null,
 ResolutionNumber varchar(512) null,
 SignDate DateTime null,
 Status varchar(512) null,
 StatusID varchar(512) null,
 TASKCONTROLLERID varchar(512) null,
 TASKSIGNERID varchar(512) null,
 TaskSubject varchar(4096) null,
 TITLE varchar(512) null,
 Comments varchar(4096) null,
 ForInfo varchar(512) null,
 Assignment varchar(512) null,
 OtherDocs varchar(512) null,
 
 DBName varchar(512) null				-- Имя базы Лотус
)
-- Сотрудники
Create table Orgs
(
 ID int IDENTITY NOT NULL ,				-- Служебное поле

 OrgID varchar(512) null,
 title varchar(512) null,
 specializations varchar(512) null
)

Это значительно упростило выгрузку в сравнении тем, если бы данные выгружались «сразу в MBAnalit». Проводить конвертацию удобнее и быстрее на SQL.

Выгрузка данных была реализована с помощью сценариев Lotus Notes.

Алгоритм здесь довольно прост:

1. Последовательно перебираются все базы (данные почти всех форм БОСС-Референт (см. Анализ) хранились в «отдельных базах» (разных файлах на жёстком диске)).
2. В каждой базе в цикле перебирались все целевые данные и выгружались в таблицы промежуточной БД.

Для выгрузки в каждой базе (кроме Сотрудников и т.п.) было создано представление с одним условием: «дата создания документа не превышает двух лет». Фильтрация таким образом работала гораздо быстрее, нежели перебор всех(!) документов и проверка даты у каждого.

Тела документов выгружались на жёсткий диск. Структура папок имела следующую структуру:

..\Lotus\ «ИД документа»\ «Тело документа», где

«Lotus» - название общей папки,

«ИД документа» - название папки, дочерней для папки «Lotus»,

«Тело документа» - само тело документа с оригинальным именем и расширением.

Пример: «C:\Lotus\000SDF45899QW87E58QW\scn_14.03.2014_15.58.18.TIFF»

Конвертация и загрузка

В результате выгрузки мы получили данные из БОСС-Референт в реляционном виде.

Используемый алгоритм конвертации и переноса достаточно подробно описан в статье SQL Server Integration Services как инструмент переноса исторических данных, но здесь данных было мало, поэтому SSIS не понадобился. Использовались простые отдельные SQL-запросы.

Напомню основные шаги:

1.В промежуточной БД были созданы таблицы, аналогичные тем, которые будут заполняться в DIRECTUM: MBAnalit, MBAnValR, MBText, SBEDoc и т.д.

2.Данные БОСС-Референт были перенесены в эти таблицы и нужным образом сконвертированы.

3.В завершение, осталось только за`insert`тить данные из соответствующих таблиц в продуктивную базу и скопировать тела документов в Файловое хранилище.

Результаты

Немного сухих цифр.

Перенесено:

• 137 000 РКК
• 83 000 Поручений
• 260 000 электронных документов
• И другие справочные данные…

Выгрузка всех данных заняла 3 часа, загрузка – 1 час + 4 часа на копирование тел документов (50 ГБ)

в файловое хранилище.

Сложности и особенности

Копирование исходных баз Lotus

Файлы баз Lotus Notes имеют достаточно большой размер и их достаточно много. Если перенос данных будет выполняться не на старом сервере, то необходимо продумать варианты копирования (по сети, через внешний жёсткий диск).

В нашем случае миграция выполнялась на новом сервере с продуктивной базой DIRECTUM, а скорость копирования по сети оказалась крайне низкой. Пришлось перетаскивать 280 ГБ с помощью внешнего жёсткого диска. Проблема, на первый взгляд, небольшая, но она имела организационные трудности (отсутствие прямого доступа к серверам, выход администратора заказчика в выходной день). Стоит иметь ввиду при планировании.

Особенности хранения справочных данных в Lotus

По сути, всё данные в Lotus хранятся в строковом виде. В некоторых случаях, если была необходимость связи по ИД (например, в местах, где указываются сотрудники, организации и т.п.), на формах был отдельный реквизит, в котором хранилось значение ИД. Но и это ещё не всё! У пользователей БОСС-Референт была возможность, как выбрать, например, существующего сотрудника, так и указать своё произвольное строковое значение. В первом случае, в служебный реквизит записывалось значение ИД сотрудника, а во втором случае, ИД принимал значение «HAND_MADE» =).

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

"Дубли" документов

У делопроизводителей была возможность осуществлять «рассылки» документов в БОСС-Референт. Но, если в DIRECTIM все пользователи работают по сути с одним объектом (РКК, ЭД) по ссылке, то здесь, при отправке документа в другие базы, создавались его копии (ИД оставался один). И эти копии начинали жить своей жизнью, у них могли менять значения реквизитов и т.д.

Эта проблема была решена с помощью приоритетов. Для каждой базы были определены приоритеты в разрезе форм БОСС-Референт (видов документов). Алгоритм выгрузки был следующий:

1. Выгружались документы из базы 1 (база с максимальным приоритетом).
2. Выгружались документы из базы 2 (с более низким приоритетом), если эти документы (сопоставление по ИД) ещё не были выгружены.
3. И так далее...

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

Выводы

Описанная архитектура переноса данных имеет следующие достоинства:

• Достаточно высокая скорость переноса данных. За счёт выполнения бОльшего числа операций на SQL. Критично, когда данных много, а время на перенос ограничено.
• Благодаря выгрузке в промежуточную БД, удалось выявить многие дефекты данных ещё до загрузки в (дубли документов, кривые значения реквизитов и т.п.).

Недостатки:

• Многоэтапность переноса. Нужно сначала запускать выгрузку, потом конвертацию и загрузку, отдельно переносить тела документов.
• Риск нарушить целостность данных в DIRECTUM, т.к. импорт выполняется прямыми SQL-запросами.

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

• Импорт договоров в систему DIRECTUM

• Сценарий Импорт записей справочников из xls-файла

• SQL Server Integration Services как инструмент переноса исторических данных