Миграция данных в СИЭР: как перенести информацию из унаследованных систем без потерь

Данная статья адресована как техническим специалистам (аналитикам-постановщикам, разработчикам, архитекторам, администраторам БД), так и бизнес-пользователям, участвующим во внедрении платформы СИЭР (Системы Исполнения Электронных Регламентов) в своей организации.

Цель публикации — поделиться имеющимся опытом, а также рассказать о разработанной в ФОРС методике миграции данных при переносе прикладных систем на платформу СИЭР. Особое внимание мы уделим следующим аспектам:

• сохранение историчности данных
• перенос информации в реестровую модель
• минимизация рисков при переходе на новую платформу.

Денис Пичаев, руководитель отдела автоматизации бизнес-процессов компании «Форс – Центр разработки» (ГК Форс)

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

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

Платформа СИЭР разработана и поставляется компанией «Эволента», она предназначена для автоматизации административно-управленческих процессов предоставления государственных и муниципальных услуг и внутриведомственных административных процессов, а также оперативного доступа к соответствующей информации. В продукте используется реестровая форма ведения записей. Это особенно удобно при оказании услуг, связанных с аттестацией и выдачей разрешений/лицензий для организаций из различных сфер деятельности. Так, например, если на основании заявления от организации принимается положительное решение о выдаче/продлении/аннулировании лицензии или разрешения, то после завершения работы с таким заявлением на платформе СИЭР будет автоматически создана или обновлена реестровая запись с данными об организации и об объекте её деятельности. Эти данные сохраняются в системе таким образом, чтобы можно было оперативно найти все записи, относящиеся к организации или объекту деятельности, а также сформировать выписку или необходимую отчетность.

В связи с этим специалистами ФОРС был разработан механизм, позволяющий переносить данные из системы, где не был предусмотрен реестровый тип хранения данных, в систему с реестровой моделью хранения данных на платформе СИЭР с сохранением всей истории операций.

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

Подготовка к миграции данных

Этот процесс следует начинать сразу после разработки основной функциональности, когда уже описаны бизнес-процессы, а в СИЭР они описываются в формате BPMN, созданы и согласованы с заказчиком статусная модель, экранные формы, структура реестровой записи, а также налажен процесс её создания и обновления.

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

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

На этом этапе у разработчиков могут возникнуть определенные трудности, связанные с разницей в структуре старой и новой базы данных. Поэтому необходимо уделить серьезное внимание приведению в соответствие формата данных. Так, например, при переносе данных из реляционной базы Oracle в NoSql базу MongoDB данные следует преобразовать в совместимый формат JSON, что потребует:

• анализа структуры исходных данных
• написания скриптов для конвертации
• проверки целостности информации после переноса.

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

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

Для этого необходимо уточнить, как работает механизм создания и обновления реестровой записи в новой системе. Напомним, что реестровая запись в СИЭР создаётся/обновляется автоматически посредством встроенных функций и собственного обработчика, который задаёт структуру записи.

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

• Прописать в скрипте миграции при переносе данных из старой системы в новую алгоритм заполнения коллекции реестровых записей на основании переносимых сущностей.
• Воспользоваться реализованным в СИЭР функционалом создания/обновления реестровой записи, адаптировав его посредством script task на BPMN схеме. Таким образом, каждое дело с признаком «мигрированное» и положительным решением будет проходить через такую задачу при попадании в СИЭР, и на его основании будет создаваться либо обновляться реестровая запись.
  Важно: чтобы соблюсти историчность данных в реестре, миграцию необходимо проводить от наиболее старых сущностей к новым.

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

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

Подробнее о втором варианте миграции реестровых записей

При реализации решения прежде всего необходимо определить место для script task на BPMN схеме. Так, в нашем случае лучшим вариантом размещения стало выделение отдельного потока операций (flow) с условием на завершенные дела с положительным решением. В данной ветке последовательно устанавливаются:

• script task с кодом на groovy
• service task со стандартными настройками для внесения записи в реестр
• service task для перевода дела в конечный статус.

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

В script task потребовалось написать средствами groovy функцию, аналогичную внутренней функции СИЭР «create License», задачей которой является передача необходимых данных из дела в лицензию. В случае первичного создания реестровой записи важно прописать генерацию id лицензии, а в случае обновления — установку нужного статуса лицензии.

Заключение

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

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

В то же время, правильно продуманная миграция в СИЭР позволяет:

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

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