Зміст
(Б-29) Інформаційна система «Муніципальний реєстр» : Керівництво адміністратора ЕМР(розширене)
1 ВВЕДЕННЯ
1.1 Область застосування:
Модернізація ІС «МР» полягає у створені:
- сервісу профілю МР;
- сервіс обміну даних з РТГК;
- сервісу обміну даних з ІС НСС;
- БД Муніципальний реєстр.
1.2 Короткий опис можливостей
Сервіс профілю МР забезпечує:
- створення та оновлення профілей за допомогою даних, отриманих із зовнішніх систем;
- матчинг профілей та їх об’єднання згідно керованих правил;
- управління дотриманням конфіденційності особистих даних профілю;
- моніторінг змін в профілях.
Сервіс обміну даних з РТГК забезпечує:
- отримання та обробку даних для створення та оновлення профілей джерела РТГК, отриманих від РТГК;
- управління згодою на збагачення особистих даних.
Сервіс обміну даних з ІС НСС забезпечує:
- отримання та обробку даних для створення та оновлення профілей джерела ІС «НСС», отриманих від ІС «НСС»;
- управління згодою на збагачення особистих даних.
БД Муніципальний реєстр забезпечує:
- зберігання даних (профілей) мешканця м.Київ.
1.3 Вимоги до кваліфікації персоналу з експлуатації системи
Таблиця 1. Вимоги до кваліфікації персоналу з експлуатації системи
| Роль | Вимоги до кваліфікації |
| Адміністратор (Системний) | · Базові знання по роботі з операційними системами; · Базові знання по роботі з базами даних; · Навички написання функціональних скриптів; · Знання англійської на рівні достатньому для читання і розуміння технічної документації без словника. |
2 ПРИЗНАЧЕННЯ ТА УМОВИ ЗАСТОСУВАННЯ
2.1 Призначення системи
В рамках модернізації ІС «МР» здійснено:
- модернізація програмного компоненту отримання даних від джерел, створення та оновлення профілей мешканців м.Київ в Системі;
- модернізація програмного компоненту валідації даних полів профілей;
- програмний компонент пошуку на співпадання профілей мешканця м.Київ по ідентифікаторам;
- програмний компонент об’єднання профілей мешканця кожного джерела під один Профайл;
- програмний компонент налаштувань достовірності об’єктів даних профілей для кожного джерела;
- програмний компонент налаштувань обов’язковості створення об’єктів даних профілей для збереження даних мешканця м.Київ в Системі ;
- модернізація програмного компоненту надання інформації з профілей по запитам зовнішніх систем.
2.2 Програмне забезпечення системи
Робоче місце Адміністратора – ПК з наступним програмним забезпеченням:
- операційні системи – Linux CentOS 7;
- система управління базами даних – PostgreSQL 9.6, MongoDB 2.6;
- програмна платформа – Framework Node js, ReactJS;
- система забезпечення версійності та інтеграції проекту – Gitlab;
- сервери додатків.
3 Основні функціональні елементи
3.1 Створення провайдера
При створені провайдера в Системі обов’язково вказується параметри:
- name - Назва джерела;
- code - Код джерела.
Для створення провайдера потрібно використовувати запит: POST {BASE_URL}/api/internal/providers { “code”: {providerCode}, “name”:{providerName} } Відповідь у разі успішного виконання: { “id”: {id}, “name”: {providerCode}, “code”: {providerName}, “creationTimestamp”: {timeStampCreate}, “modificationTimestamp”: {timeStampModif} } При успішному створені провайдера Система генерує:
- id - Ідентифікатор джерела.
3.2 Редагування провайдера
Для редагування провайдера потрібно використовувати запит: PUT {BASE_URL}/api/internal/providers/{providerId} { “code”: {newProviderCode}, “name”:{newProviderName} } Відповідь у разі успішного виконання: { “id”: {providerId}, “name”: {newProviderName}, “code”: {newProviderCode}, “creationTimestamp”: {timeStampCreate}, “modificationTimestamp”: {timeStampModif} }
3.3 Отримання списку провайдерів
Для отримання списку провайдерів потрібно використовувати запит: GET {BASE_URL}/api/internal/providers Відповідь у разі успішного виконання: [ { “id”: {providerId1}, “name”: {providerName1}, “code”: {providerCode1}, “creationTimestamp”: {timeStampCreate1}, “modificationTimestamp”: {timeStampModif1} }, { “id”: {providerId2}, “name”: {providerName2}, “code”: {providerCode2}, “creationTimestamp”: {timeStampCreate2}, “modificationTimestamp”: {timeStampModif2} } ]
3.4 Отримання провайдера по коду
Для отримання списку провайдерів потрібно використовувати запит: GET base_url/api/internal/providers/code/{providerCode} Відповідь у разі успішного виконання: { “id”: {id}, “name”: {providerCode}, “code”: {providerName}, “creationTimestamp”: {timeStampCreate}, “modificationTimestamp”: {timeStampModif} }
3.5 Отримання провайдера по ідентифікатору
Для отримання списку провайдерів потрібно використовувати запит: GET {BASE_URL}/api/internal/providers/{id} Відповідь у разі успішного виконання: { “id”: {id}, “name”: {providerCode}, “code”: {providerName}, “creationTimestamp”: {timeStampCreate}, “modificationTimestamp”: {timeStampModif} }
3.6 Налаштування достовірності та обов’язковості об’єктів даних профілей для провайдера
Для налаштування достовірності об’єктів провайдера потрібно використовувати запит:
POST {BASE_URL}/api/internal/providers/{providerId}/field-settings
{
“mandatoryFields”: [ {field1}, {field2} ],
“verifiedFields”: [ {field1}, {field2} ]
}
де: {field1}, {field2} – об’єкти профіля, як “Uren”, “Itin” і так далі. Повний перелік налаштувань об’єктів профіля для провайдерів РТГК та ІС «НСС» представлено в Таблиця 2, Таблиця 3 відповідно.
Таблиця 2. Налаштування об’єктів даних РТГК
| № з/п | Назва об'єкта | Значення об'єкта | Достовірність | Обов’язковість |
| 1 | Name | ПІБ людини | Достовірно | Обов’язково |
| 2 | Gender | Стать | Достовірно | Обов’язково |
| 3 | Citizenship | Громадянство | Достовірно | Необов’язково |
| 4 | Document | Документи | Достовірно | Обов’язково |
| 5 | Uren | УНЗР людини | Достовірно | Необов’язково |
| 6 | BirthDate | Дата народження людини | Достовірно | Необов’язково |
| 7 | PlaceOfBirth | Місце народження людини | Достовірно | Необов’язково |
| 8 | RegistrationAddress | Адрес реєстрації | Достовірно | Обов’язково |
| 9 | Address | Адреси | Достовірно | Обов’язково |
Таблиця 3. Налаштування об’єктів даних ІС «НСС»
| № з/п | Назва об'єкта | Значення об'єкта | Достовірність | Обов’язковість |
| 1 | Name | ПІБ людини | Достовірно | Обов’язково |
| 2 | Gender | Стать | Достовірно | Необов’язково |
| 3 | Document | Документи | Достовірно | Обов’язково |
| 4 | Itin | Ідентифікаційний номер людини | Достовірно | Обов’язково |
| 5 | Uren | УНЗР людини | Достовірно | Необов’язково |
| 6 | BirthDate | Дата народження людини | Достовірно | Необов’язково |
| 7 | RegistrationAddress | Адрес реєстрації | Достовірно | Необов’язково |
| 8 | Address | Адреси | Достовірно | Необов’язково |
| 9 | Phone | Номери телефонів людини | Недостовірно | Необов’язково |
| 10 | Адреси електронної пошти людини | Недостовірно | Необов’язково | |
| 11 | BankCard | Дані карти | Достовірно | Обов’язково |
| 12 | BankAccount | Дані банківського рахунку | Достовірно | Обов’язково |
| 13 | Beneficiary | Дані пільговика | Достовірно | Обов’язково |
| 14 | Benefits | Дані по пільгам | Достовірно | Необов’язково |
| 15 | Job | Дані по работі | Достовірно | Необов’язково |
3.7 Редактування достовірності та обов’язковості об’єктів даних профілей для провайдера
Для редактування достовірності об’єктів провайдера потрібно використовувати запит:
PUT {BASE_URL}/api/internal/providers/{providerId}/field-settings
{
“mandatoryFields”: [ {field1}, {field2} ],
“verifiedFields”: [ {field1}, {field2} ]
}
3.8 Отримання переліку достовірних та обов’язкових об’єктів даних профілей для провайдера
Для отримання достовірних та обов’язкових об’єктів провайдера потрібно використовувати запит:
GET {BASE_URL}/api/internal/providers/{providerId}/field-settings
Відповідь у разі успішного виконання:
{
“providerId”: {providerId},
“mandatoryFields”: [ {field1}, {field2} ],
“verifiedFields”: [ {field1}, {field2} ]
}
3.9 Отримання переліку провайдерів з переліком достовірних та обов’язкових об’єктів даних профілей для провайдерів
Для отримання переліку провайдерів з переліком достовірних та обов’язкових об’єктів провайдерів потрібно використовувати запит: GET {BASE_URL}/api/internal/providers/field-settings Відповідь у разі успішного виконання: [ { “providerId”: {providerId1}, “mandatoryFields”: [ {field1}, {field2} ], “verifiedFields”: [ {field1}, {field2} ] }, { “providerId”: {providerId2}, “mandatoryFields”: [ {field1}, {field2} ], “verifiedFields”: [ {field1}, {field2} ] } ]
3.10 Видалення налаштувань достовірності та обов’язковості об’єктів даних профілей для провайдера
Для видалення налаштувань достовірності та обов’язковозті об’єктів потрібно використовувати запит: DELETE {BASE_URL}/api/internal/providers/{providerId}/field-settings
4 АВАРІЙНІ СИТУАЦІЇ
4.1 Дії в аварійних випадках
Цим керівництвом щодо експлуатації програми рекомендовано створення резервних копій. Створення копій виконується за допомогою команди: pg_dump -h 10.14.5.8 -p 5432 -U postgres -F c -b -v -f “file_db.dmp” “rnp” Як результат, отримаємо файл «db.dmp».
4.2 Дії по відновленню програм та/або даних
Рекомендовані дії по відновленню програм. Використовуючи електронний носій (диск) із програмним забезпеченням, потрібно повторити процедуру розгортання ПЗ згідно з «Загальна інструкція по розгортанню та налагодженню». Рекомендовані дії по відновленню бази даних (даний крок допускається пропустити при первинному введенні в експлуатацію). Маючи файл «db.dmp», виконується команда відновлення бази даних. Команда наведено нижче: pg_restore -h 10.14.5.8 -p 5432 -U postgres -d “ rnp ” -v -c -F c “file_db.dmp” Як результат, базу даних буде відновлено. Після внесення змін до даних веб-серверу його потрібно перезапустити. Для перезапуску веб-серверу: $ sudo systemctl reload nginx.service