« Назад к База знаний СПГУ

Типовое решение Регионального реестра

Типовое решение Регионального реестра

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

Нормативно-правовая база

Методические рекомендации

Методические рекомендации по ведению и заполнению Типового реестра версии 4.0

Разделы Типового решения регионального реестра версии 4.0

  1. Раздел "Мои задачи"
  2. Раздел "Услуги"
  3. Раздел "Функции"
  4. Раздел "НПА"
  5. Раздел "Рабочие документы"
  6. Раздел "Органы власти"
  7. Раздел "Открытые данные"

Руководство пользователя Типового решения регионального реестра версии 4.0

скачать

Разделы Типового решения регионального реестра версии 4.1

  1. Раздел "Мои задачи"
  2. Раздел "Услуги"
  3. Раздел "Функции"
  4. Раздел "НПА"
  5. Раздел "Документы"
  6. Раздел "Органы власти"
  7. Раздел "Открытые данные"

Руководство пользователя Типового решения регионального реестра версии 4.1

скачать

Информационное взаимодействие с внешними системами

В Типовом реестре реализованы следующие программные интерфейсы, предназначенные для осуществления взаимодействия с внешними системами:

  1. Сервис инкрементального обновления.
  2. Сервис передачи основных сведений об объектах реестра.
  3. Сервис загрузки органов власти (организаций)

Актуальная версия типового решения

Актуальная версия типового решения 4.1.37

Необходимые для обновления исходные материалы доступны здесь

Инструкция по обновлению

Инструкция по обновлению типового решения реестра государственных и муниципальных услуг до версии 4.1.37

Миграция данных из реестра версии 4.0

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

  1. Отредактируйте скрипт создания чистой БД реестра 4.1 - файл \bin\create-initial-target-db.sh. Изменяемые параметры приведены здесь
  2. Выполните настроенный скрипт \bin\create-initial-target-db.sh
  3. Отредактируйте скрипт переноса данных БД реестра 4.0 в реестра 4.1 - файл \bin\migrate.sh. Изменяемые параметры приведены здесь.
  4. Выполните настроенный скрипт \bin\migrate.sh
  5. При необходимости для переноса версий для сравнения изменения объектов реестра (сравнение, которое открывается из истории изменения объекта), отредактируйте скрипт переноса версий для сравнения bin\migrate_xml_data.sh. Параметры скрипта приведены здесь.
  6. Выполните настроенный скрипт bin\migrate_xml_data.sh.
  7. В случае, если приложения реестра 4.0 и 4.1 лежат на разных серверах, необходимо перенести папку, указанную в параметре STORAGE_ROOT_DIRECTORY_PATH таблицы system_properties, на сервер приложения реестра 4.1.

Контроль полноты и корректности миграции данных

После завершения миграции для контроля полноты и корректности данных, перенесенных из Федерального реестра версии 4.0, необходимо воспользоваться журналом логирования, сформированным в ходе миграции, а также типовыми запросами к БД и проверками ее целостности. Показателями полноты и корректности миграции служат количественные показатели переданных записей по ключевым таблицам сущностей, а также структурная целостность базы данных ФРГУ версии 4.0 после миграции. Журнал логирования содержит секции в соответствии со сценарием проведения миграции. Секция миграции данных представляет собой записи следующего вида:

3,"(4.0) (user_notification_statuses): contains 77 entity","2016-11-25 11:55:38.003299",user_notification_statuses,NULL
4,"(4.1) (user_notification_statuses): inserted 77 entity","2016-11-25 11:55:38.084691",user_notification_statuses,NULL
5,"(4.0) (service_2_work_document): contains 249884 entity","2016-11-25 11:56:27.998037",service_2_work_document,NULL
6,"(4.1) (service_2_work_document): inserted 249884 entity","2016-11-25 11:56:52.507768",service_2_work_document,NULL

где

  • первое значение – уникальное значение строки логирования;
  • (4.0) или (4.1) [наименование таблицы, записи которой мигрированы]– версия ФРГУ, указывающая на принадлежность информации к записям БД источника или целевой БД, куда переносятся данные. Если строка содержит (4.0), то строка описывает количество записей, взятых из таблицы БД ФРГУ версии 4.0; если (4.1), то количество вставленных записей в таблицу целевой БД ФРГУ версии (4.1);
  • [количество обработанных записей таблицы];
  • [дата-время начала процесса];
  • [наименование таблицы, записи которой были мигрированы].

Для контроля полноты необходимо проследить за соответствием количества записей таблиц основных сущностей (услуги, функции, ОГВ, офисы). Анализ НПА и рабочих документов не относится к простому сопоставлению количества записей, поскольку они мигрируются и затем обрабатываются по принципу участия в услугах/функциях (Рабочие документы или НПА, которые не используются ни в одной услуге/функции, не переносятся в целевую БД) , поэтому полноту данных по этим сущностям можно проверить только с помощью выполнения запроса к БД источника и целевой БД.

Для анализа полноты миграции НПА необходимо осуществить следующие действия:
1. Выполните запрос к БД ФРГУ версии 4.0:

 «SELECT count(DISTINCT la.id)
 FROM legal_act la
 LEFT JOIN LEGAL_ACT_SERVICE las ON la.id = las.legal_act_id
 LEFT JOIN service_2 s ON s.id = las.service_id
 LEFT JOIN tkmv t ON la.id = t.legal_act_id
 LEFT JOIN adm_regulation ar ON la.id = ar.legal_act_id
 WHERE s.id IS NOT NULL OR t.id IS NOT NULL OR ar.id IS NOT NULL;»,

возвращающий количество НПА, связанных с услугами и функциями, в ФРГУ 4.0.
2. Выполните запрос к БД ФРГУ 4.1:

 «SELECT count(DISTINCT la.id)
 FROM legal_act la
 LEFT JOIN LEGAL_ACT_SERVICE las ON la.id = las.legal_act_id
 LEFT JOIN service_2 s ON s.id = las.service_id
 LEFT JOIN tkmv t ON la.id = t.legal_act_id
 LEFT JOIN adm_regulation ar ON la.id = ar.legal_act_id
 WHERE s.id IS NOT NULL OR t.id IS NOT NULL OR ar.id IS NOT NULL;», 

возвращающий количество НПА, связанных с услугами и функциями, в ФРГУ 4.1.
3. Сравните количество НПА, полученное в результате выполнения первого и второго запроса. Оно должно совпасть.
Для анализа полноты миграции рабочих документов необходимо осуществить следующие действия:
1. Выполните запрос к БД ФРГУ версии 4.0:

 «SELECT count(1)
 FROM (
      SELECT DISTINCT wd.id
      FROM _work_document wd
        INNER JOIN service_2_work_document s2wd ON wd.id = s2wd.work_document_id
        INNER JOIN service_2 s ON s.id = s2wd.service_id
    ) inn;», 

возвращающий количество рабочих документов, связанных с услугами и функциями, в ФРГУ 4.0.
2. Выполните запрос к БД ФРГУ 4.1:

 «SELECT count(1)
 FROM (
      SELECT DISTINCT wd.id
      FROM _work_document wd
        INNER JOIN service_2_work_document s2wd ON wd.id = s2wd.work_document_id
        INNER JOIN service_2 s ON s.id = s2wd.service_id
    ) inn;»,

возвращающий количество рабочих документов, связанных с услугами и функциями, в ФРГУ 4.1.
3. Сравните количество рабочих документов, полученное в результате выполнения первого и второго запроса. Оно должно совпасть. Для оценки целостности структуры мигрированных данных необходимо провести анализ на отсутствие строк с ошибками в секциях лога «RESTORE INDEXES» и «RESTORE CONSTRAINTS».



Дата обновления сведений: 29.11.18г.

0 Вложения
11794 Просмотров
Среднее (0 Голоса)
Средний рейтинг 0.0 звезд из 5.
Комментарии
Пока нет комментариев. Будь первым.