Зміст
(Б-12) Програмна платформа для надання електроних послуг, у тому числі адміністративних : Технічний опис
2.1. Структура системи
Програмний модуль «Система замовлення відео контенту» (далі Система або СЗВ) – це комплекс сервісів, які взаємодіють між собою та із зовнішніми системами, та забезпечуються функціонування системи в цілому. Верхнерівнева схема побудови рішення відображена на Рисунок 1:
Рисунок 1. Верхнерівнева схема побудови рішення
АРМ Адміністратора – автоматизоване робоче місце адміністратора, якому доступний функціонал Системи у відповідності до рольової моделі.
АРМ Оператора – автоматизоване робоче місце оператора, якому доступний функціонал Системи у відповідності до рольової моделі.
Сервіс адміністрування - сервіс, що надає можливість налаштувань, необхідних для функціонування Системи та користувачів. Включає в себе Мікросервіс управління довідниками та Мікросервіс управління користувачами.
Сервіс обліку та управління замовленнями – сервіс, що забезпечує виконання операцій з даними картки замовлення.
Сервіс обліку та управління камерами – сервіс, що забезпечує можливість виконання операцій з даними картки камери.
Сервіс обміну з ОКК – сервіс, що забезпечує обробку замовлення від Користувача ОКК, та забезпечує надання статусу виконання замовлення.
Сервіс обміну з ІАС «Майно» - сервіс, що забезпечує надання даних про камери до ГІС-системи ІАС «Майно» з метою подальшого відображення камер на карті міста.
Сервіс обміну даними з КП Інформатика – сервіс, що забезпечує отримання актуальних даних камер з програмного рішення КСВС з метою їх подальшого використання в Системі.
БД – база даних, в якій зберігаються замовлення та отримані дані камер.
ОКК – Особистий кабінет киянина, інформаційна система в якій житель міста Києва може створити замовлення на отримання відео контенту.
ІАС «Майно» - інформаційно-аналітична система «Майно».
КП Інформатика - Комунальне підприємство «Інформатика» виконавчого органу Київської міської ради.
2.2. Відомості про АС, необхідні для забезпечення експлуатації системи
2.2.1. Технічні засоби, що забезпечують роботу системи
Для забезпечення працездатності Системи використовуються технічні засоби, що мають характеристики, наведені в Таблиця 1: Таблиця 1. Характеристики апаратного забезпечення
Тип | Вимоги |
Віртуальний сервер БД | CPU 4, Memory 8GB, HDD 500GB |
Віртуальний сервер АРР | CPU 4, Memory 16GB, HDD 250GB |
Віртуальний сервер FileStorage | CPU 2, Memory 2GB, HDD 250GB |
Віртуальний сервер БД резервний | CPU 4, Memory 8GB, HDD 500GB |
Віртуальний сервер APP резервний | CPU 4, Memory 16GB, HDD 250GB |
Віртуальний сервер FileStorage резервний | CPU 2, Memory 2GB, HDD 250GB |
Віртуальний сервер БД та APP тестовий | CPU 12, Memory 16GB, HDD 500GB |
Віртуальний сервер моніторингу | CPU 1, Memory 8GB, HDD 100GB |
Віртуальний cервер забезпечення версійності, інтеграції та відслідковування помилок |
2.2.2. Опис програмно-апаратного забезпечення
В склад системи входить загальносистемне та прикладне програмне забезпечення. Верхнерівнева схема побудови рішення представлена на Рисунок 2:
Рисунок 2. Верхнерівнева архітектурна схема побудови рішення
Апаратне забезпечення – зберігання даних для управління інформаційними інфраструктурами.
Платформа OpenShift – це відкрита і розширювана платформа додатків-контейнерів, яка дозволяє за допомогою спеціальних об’єктів і механізмів швидко розробляти програми, легко розгортати і масштабувати рішення, обслуговувати життєвий цикл команд і додатків в довгостроковій перспективі.
Контейнер СЗВ – низькорівневий програмний компонент зі своїм АРІ, в рамках якого здійснюється управління та працезабезпечення СЗВ.
СЗВ – програмний модуль «Система замовлення відео-контенту».
Операційна система – це базовий комплекс програм, що виконує управління апаратною складовою комп'ютера або віртуальної машини; забезпечує керування обчислювальним процесом і організовує взаємодію з користувачем.
В якості мови розробки інтерфейсів користувача (фронт енд) використано мову Angular 5. В якості мови розробки бізнес-логіки (бек енд) – JavaScript, платформа NodeJS 8+. Сховище даних на базі СКБД PostgreSQL.
2.3. Опис функціонування системи і частин системи
Система містить наступні компоненти, що забезпечують її функціонування:
- сервіс обміну з ОКК, який забезпечує виконання наступних функцій:
- отримання пошукового запиту даних про камери; - надання відповіді в рамках запиту на пошук даних про камери в ОКК; - отримання замовлення відео контенту від ОКК, що містить дані замовлення, камери тощо. Передача замовлення до Сервісу обліку та управління замовленнями; - надання статусу замовлення до ОКК;
- сервіс обміну з КП Інформатика, який забезпечує:
- отримання даних про камери від КП «Інформатика»; - передачу отриманих даних до Сервісу обліку та управління камерами;
- сервіс обміну та управління камерами, який забезпечує:
- отримання даних про камери від Сервісу обміну з КП «Інформатика»; - обробку та збереження до БД отриманих даних про камери; - пошук та перегляд даних про камери в БД; - формування та передачу даних про камери до Сервісу обміну з ІАС «Майно»;
- сервіс обліку та управління замовленнями, що забезпечує:
- запит даних замовлення до БД - пошук даних про замовлення; - читання даних про замовлення; - управління замовленнями, а також їх статусами;
- сервіс обміну з ІАС «Майно», що забезпечує:
- передачу даних про камери до ІАС «Майно» для подальшого відображення їх на карті міста;
- сервіс адміністрування, що забезпечує:
- управління користувачами; - управління довідниками. Невід’ємним компонентом, що забезпечує функціонування, є рольова модель (див. Таблиця 2). Права доступу ролей в Системі забезпечуються виділенням для кожної ролі власного набору рівнів доступу до відповідних функцій. Таблиця 2. Рольова модель
Назва | Опис ролі та права доступу |
---|---|
АРМ Оператора | Далі – Оператор. Рівень доступу до функцій Системи в рамках наданих прав: * робота з камерами (пошук, редагування, логічне видалення камери); * робота з замовленнями (пошук, створення, перегляд, логічне видалення замовлення, зміна статусу замовлення); |
АРМ Адміністратора | Далі – Адміністратор. Рівень доступу до функцій Системи в рамках наданих прав: * перегляд, створення, редагування, видалення користувачів (Операторів) та налаштування їх прав та ролей; * створення, редагування, видалення довідників системи. |
Дані замовлення та камер в Системі представлені у вигляді сутностей, які пов’язані між собою зв’язками. Моделі даних, що дозволяють описати логічну структуру сутності Замовлення та сутності Камера, наведені на Рисунок 3 та Рисунок 4 відповідно.
Рисунок 3. Структура даних сутності Замовлення
Таблиця 3. Опис структури даних сутності Замовлення
Назва атрибуту | Тип даних | Обов’язковий / необов’язковий | Коментарі |
---|---|---|---|
Дані користувача | |||
Прізвище | VARCHAR | Обов’язковий | |
Ім’я | VARCHAR | Обов’язковий | |
По батькові | VARCHAR | Необов’язковий | |
Телефон | INT | Обов’язковий | |
VARCHAR | Необов’язковий | ||
Параметри замовлення | |||
Дата замовлення | DATA | Обов’язковий | Дата створення замовлення |
Дата контенту | DATA | Обов’язковий | Дата за яку користувачу необхідно відео |
Час початку контенту | INT | Обов’язковий | Час початку замовленого відео |
Час закінчення контенту | INT | Обов’язковий | Час закінчення замовленого відео |
Статус замовлення | |||
Тип статусу | value | Обов’язковий | Довідник «Статуси» |
Дата статусу | DATA | Обов’язковий | |
Час статусу | INT | Обов’язковий | |
Результат замовлення | URL | Необов’язковий | Обов’язковий тільки для статусу Виконано |
Адреса | |||
Країна | VARCHAR | Необов’язковий | |
Область | VARCHAR | Необов’язковий | |
Район | VARCHAR | Необов’язковий | |
Населений пункт | VARCHAR | Обов’язковий | |
Адміністративний район | VARCHAR | Необов’язковий | |
Вулиця | VARCHAR | Обов’язковий | |
Будинок | INT | Обов’язковий | |
Літера будинку | INT | Необов’язковий | |
Технічні характеристики | |||
ID камери | VARCHAR | Обов’язковий | ID камери з комплексної системи відеоспостереження міста Києва. |
IP адрес камери | VARCHAR | Обов’язковий | |
Тип камери | value | Обов’язковий | Довідник «Типи камер» |
Дата встановлення | DATA | Необов’язковий | |
Наявність камер на карті | Boolean | Обов’язковий | Наявність камер на карті, тобто наявність координат для камери. |
Широта | VARCHAR | Обов’язковий | |
Довгота | VARCHAR | Обов’язковий | |
Публічність камери | Boolean | Обов’язковий | Публічна камери чи ні |
Дозвіл для замовлення архівного відео-контенту | Boolean | Обов’язковий | Так Ні |
Рисунок 4. Структура даних сутності Камера
Таблиця 4. Структура даних сутності Камера
Назва атрибуту | Тип даних | Обов’язковий / необов’язковий | Коментарі |
Адреса | |||
Країна | VARCHAR | Необов’язковий | |
Область | VARCHAR | Необов’язковий | |
Район | VARCHAR | Необов’язковий | |
Населений пункт | VARCHAR | Обов’язковий | |
Адміністративний район | VARCHAR | Необов’язковий | |
Вулиця | VARCHAR | Обов’язковий | |
Будинок | INT | Обов’язковий | |
Літера будинку | VARCHAR | Необов’язковий | |
Технічні характеристики | |||
ID камери | VARCHAR | Обов’язковий | ID камери з комплексної системи відеоспостереження міста Києва. |
IP адрес камери | VARCHAR | Обов’язковий | |
Тип камери | Value | Обов’язковий | Довідник «Типи камер» |
Дата встановлення | DATA | Необов’язковий | |
Наявність камер на карті | Boolean | Обов’язковий | Наявність камер на карті, тобто наявність координат для камери. |
Широта | VARCHAR | Обов’язковий | |
Довгота | VARCHAR | Обов’язковий | |
Публічність камери | Boolean | Обов’язковий | Публічна камери чи ні |
Дозвіл для замовлення архівного відео-контенту | Boolean | Обов’язковий | Так Ні |
2.3.1. Сервіс обміну з ОКК
Сервіс обміну з ОКК представляє собою набір програмних інтерфейсів у вигляді мікросервісів та забезпечує можливість обміну даними з ОКК в частині отримання пошукових запитів на отримання даних про камери, надання відповіді на пошукові запити у вигляді даних про камери засобами Мікросервісу пошуку камер, а також можливість обробки замовлень та надання відповідних статусів виконання замовлень до ОКК засобами Мікросервісу обміну даними з ОКК.
2.3.1.1. Мікросервіс пошуку камер. Пошук камер в ОКК
Рисунок 5. Процес отримання та обробки пошукового запиту даних про камери від ОКК
Для створення замовлення на отримання відео контенту Користувачу ОКК необхідно здійснити попередній пошук камери в Системі. Для здійснення пошуку необхідно ввести пошукові параметри камери:
- вулиця;
- номер будинку;
- додатково може бути обрано тип камери.
ОКК, після введення пошукових даних камери, формує пошуковий запит, в якому вказує пошукові параметри, вказані Користувачем ОКК, та передає пошуковий запит до Мікросервісу пошуку камер. Мікросервіс пошуку камер надсилає отриманий від ОКК пошуковий запит до Сервісу обліку та управління камерами. Сервіс обліку та управління здійснює пошук картки камери за вказаними пошуковими даними. У випадку, якщо за вказаними пошуковими даними було знайдено відповідну камеру, Сервіс обліку та управління камерами формує відповідь, яка містить адресу та технічні характеристики камери (відповідно до Таблиця 4. Структура даних сутності Камера) та в рамках відповіді направляє сформовані дані до Мікросервісу пошуку камер, який в свою чергу отриману відповідь надає до ОКК. ОКК відображає Користувачу ОКК отримані дані камери. На основі отриманих даних камери Користувач ініціює створення замовлення на отримання відео контенту.
У випадку, коли за вказаними пошуковими параметрами даних камери не знайдено, Сервіс обліку та управління камерами формує відповідь про відсутність даних та направляє її до Мікросервісу пошуку камер, який в свою чергу передає отриману відповідь до ОКК. ОКК в такому випадку інформує Користувача ОКК про відсутність камер за вказаними пошуковими параметрами.
2.3.1.2. Мікросервіс обміну даними з ОКК. Створення замовлення через ОКК
Рисунок 6. Процес створення замовлення на отримання відео контенту через ОКК
В рамках процесу створення замовлення Користувачем ОКК попередньо має бути здійснений пошук відповідної камери (детально див. Рисунок 5. Процес отримання та обробки пошукового запиту даних про камери від ОКК). Користувач, окрім даних обраної камери, вказує також параметри замовлення, а саме:
- дата замовлення;
- дата контенту;
- час початку контенту;
- час закінчення контенту.
Детальний опис всіх необхідних та обов’язкових параметрів замовлення наведено в Рисунок 3. Структура даних сутності Замовлення та Таблиця 3. Опис структури даних сутності Замовлення.
ОКК формує запит з отриманими даними замовлення (дані користувача, дані камери, параметри замовлення) та виконує надсилання запиту до Мікросервісу обміну даними з ОКК. Мікросервіс обміну даними з ОКК с свою чергу виконує направлення отриманих даних замовлення до Сервісу обліку та управління замовленнями.
Сервіс обліку та управління замовленнями виконує запис отриманих даних до БД Замовлення, в результаті успішного запису замовлення до БД, повертає до Мікросервісу обміну даними з ОКК підтвердження створення замовлення у вигляді номеру замовлення.
Мікросервіс обміну даними з ОКК формує підтвердження створення замовлення та статус замовлення, передає його до ОКК. ОКК виконує інформування Користувача ОКК у вигляді відображення підтвердження створення замовлення, номер замовлення та статус замовлення.
2.3.1.3. Мікросервіс обміну даними з ОКК. Надання статуса замовлення в ОКК
Рисунок 7. Процес надання зміненого статусу замовлення до ОКК
За результатами розгляду замовлення Оператор має можливість зміни статусу замовлення. В рамках процесу зміни статусу замовлення Сервіс обліку та управління замовленнями отримує змінений статус (значення статусу обирається із довідника статусів). Сервіс обміну та управління замовленнями виконує зміну статусу для відповідного замовлення, та надає змінений статус до Мікросервісу обміну даними з ОКК.
В залежності від зміненого статусу замовлення від Мікросервісу обміну даними з ОКК до ОКК надається відповідне інформування:
- У випадку, коли Оператор змінив статус замовлення на «Виконано», до ОКК направляється статус замовлення «Виконано» та надається посилання на файл відео контенту;
- У випадку, коли Оператор змінив статус замовлення на «Відмовлено», до ОКК направляється статус замовлення «Відмовлено» та надається причина відмови, яку вказав Оператор;
- У випадку, коли Оператор змінив статус замовлення на «У роботі», до ОКК направляється статус замовлення «У роботі».
При будь-якій зміні статусу замовлення в ОКК відбувається інформування Користувача ОКК.
В рамках надання статусу замовлення ОКК повертає відповідь, що містить підтвердження отримання змінених даних, до Мікросервісу обміну даними з ОКК.
2.3.2. Сервіс обміну з КП Інформатика
Сервіс обміну з КП Інформатика представляє собою набір програмних інтерфейсів та забезпечує можливість обміну даними з КП Інформатика в частині отримання даних про камери та передачі отриманих даних до Сервісу обліку та управління камери, для збереження отриманої інформації та подальшого її використання в Системі.
Рисунок 8. Процес отримання даних про камери від КП «Інформатика»
На стороні КП Інформатика згідно з регламентом обміну даними формується інформація про камери з КСВС. При сформованих даних про камери відбувається передача даних про камери до Сервісу обміну даними з КП Інформатика. В рамках отриманого запиту передаються дані згідно з Рисунок 4. Структура даних сутності Камера та Таблиця 4. Структура даних сутності Камера. Сервіс обміну з КП Інформатика активує обробку отриманих даних на повноту та коректність. У випадку, коли від КП Інформатика було отримано неповні або некоректні дані, Сервіс обміну даними з КП Інформатика формує відповідь з помилкою та в рамках відповіді перенаправляє до КП Інформатика. У випадку, коли дані від КП Інформатика успішно пройшли валідацію, Сервіс обміну з КП Інформатика передає дані про камери до Сервісу обліку та управління камерами.
Сервіс обліку та управління камери, в рамках отриманих даних про камери, активує пошук камер в БД Камери на наявність вже існуючих камер. У випадку, коли при пошуку співпадінь в БД не знайдено, Сервіс обліку та управління камери ініціює створення нової картки камери. У випадку, коли при пошуку знайдено відповідну картку камери, Сервіс обліку та управління камерами ініціює оновлення відповідної картки камери.
Надсилання даних про камери відбується по факту їх оновлення в КП Інформатика згідно з регламентом обміну. Про факту надходження команди про оновлення даних до Сервісу обміну з КП Інформатика, ініціюється формування та направлення оновлених даних до Сервісу обліку та управління камерами.
2.3.3. Сервіс обліку та управління камерами
Сервіс обліку та управління камерами представляє собою набір програмних інтерфейсів та забезпечує можливість отримання даних про камери, обробку та збереження даних про камери в БД, надає можливість виконувати пошук та переглядати дані про камери (у відповідності до прав доступу згідно з рольовою моделлю), забезпечує формування та передачу даних про камери до Сервісу обміну з ІАС «Майно».
Рисунок 9. Процес пошуку даних камери оператором
Користувач з роллю «Оператор» має можливість в рамках Сервісу обліку та управління камерами здійснювати пошук даних про камери. Пошук даних про камери в БД відбувається шляхом надання запиту, що містить наступні дані:
- адреса камери;
- тип камери (опціонально);
- ID камери.
Параметри запиту можуть бути вказані за принципом «та»/ «або».
Сервіс обліку та управління камерами направляє пошукові параметри до БД Камери. В БД Камери здійснюється пошук відповідно до пошукових параметрів. В результаті пошуку до Сервісу обліку та управління камерами повертаються наступні дані (згідно з Таблиця 4. Структура даних сутності Камера):
- ID камери;
- IP камери;
- тип камери;
- дата встановлення камери (за наявності).
- вулиця розміщення камери;
- номер будинку розміщення камери;
- наявність камер на карті;
- широта;
- довгота;
- публічність камери;
- дозвіл на замовлення архівного відео-контенту.
Сервіс обліку та управління камерами виконує обробку отриманих даних та відображає оброблені дані Оператору. В рамках перегляду картки камери надаються дані адреси розташування та технічні характеристики камери.
В рамках отриманих даних камери, Оператор має можливість виконати операції редагування та логічного видалення картки камери (див. Рисунок 10 та Рисунок 11).
Приклад форми пошуку камери відображено на Рисунок 10:
Рисунок 10. Приклад форми пошуку камери
Рисунок 11. Процес редагування даних картки камери
В рамках перегляду картки камери, Оператор має можливість редагувати дані картки камери. Оператор змінює необхідні дані та ініціює збереження змін. Відредаговані дані картки камери потрапляють до Сервісу обліку та управління камери, де проходять перевірку на повноту та коректність. У випадку успішної перевірки відредагованих даних, Сервіс обліку та управління камерами направляє змінені дані до БД камери, де виконується збереження змінених даних. В рамках відповіді від БД надається підтвердження збереження змінених даних камери. Сервіс обліку та управління камерами формує повідомлення про успішне виконання редагування даних камери та інформує Оператора про успішне виконання операції редагування.
Рисунок 12. Процес логічного видалення картки камери
В рамках перегляду картки камери, Оператор має можливість видаляти картку камери. Під видаленням в системі відбувається логічне видалення, тобто картка камери стає недоступна для пошуку, перегляду та редагування, при чому сама інформація в БД зберігається.
Оператор ініціює видалення картки камери, вказавши причину видалення. Дані про видалення передаються до Сервісу обліку та управління камерами, де проходять перевірку на наявність вказаної причини. При успішному проходженні перевірки Сервіс обліку та управління камерами направляє команду логічного видалення до БД Камери. В БД для відповідної камери встановлюється ознаки недоступності та не активності. В результаті виконання операції логічного видалення до Сервісу обліку та управління камерами повертається підтвердження виконання операції. Сервіс обліку та управління камерами формує повідомлення про успішне виконання операції та інформує Оператора.
2.3.4. Сервіс обліку та управління замовленнями
Сервіс обліку та управління замовленнями представляє собою набір програмних інтерфейсів та забезпечує можливість здійснення пошуку замовлень, перегляду, запису замовлень, а також забезпечує обмін даними з Мікросервісом обміну даними з ОКК в частині отримання замовлень, надання статусу замовлення.
Рисунок 13. Процес пошуку даних замовлення Оператором
Користувач з роллю «Оператор» має можливість в рамках Сервісу обліку та управління замовлення здійснювати пошук даних замовлення. Пошук даних про замовлення в БД відбувається шляхом надання запиту, що містить наступні дані:
- дані користувача;
- параметри замовлення;
- статус замовлення;
- дані камери.
Структура даних запиту відповідно з Таблиця 3. Опис структури даних сутності Замовлення.
Сервіс обліку та управління замовленнями направляє команду, що містить, пошукові дані до БД Замовлення. В БД здійснюється пошук замовлень у відповідності до пошукових параметрів. У випадку успішного пошуку БД повертає до Сервісу обліку та управління замовленнями дані замовлення:
- ПІБ користувача, що створив замовлення;
- телефон користувача;
- дата створення замовлення;
- адреса розташування камери;
- поточний статус замовлення.
Сервіс обліку та управління замовленнями виконує обробку отриманих даних та формує повідомлення про успішне виконання пошуку з даними замовлення, та інформує Оператора повідомленням, що містить картку замовлення з отриманими даними.
У випадку, коли за пошуковими параметрами в БД не знайдено відповідних замовлень, БД повертає відповідь про відсутність результату пошуку до Сервісу обліку та управління замовленнями. Сервіс в свою чергу формує відповідь про відсутність результату пошуку та інформує Оператора.
В рамках знайденої картки замовлення Оператор має можливість виконання наступних операцій:
- перегляду картки замовлення;
- логічного видалення картки замовлення з вказанням причини видалення.
Рисунок 14. Процес створення замовлення Оператором
В рамках Сервісу обліку та управління замовленнями користувач з роллю «Оператор» має можливість створення картки замовлення. В рамках створення картки замовлення Оператор заповнює наступні дані:
- дані камери:
- вулиця;
- номер будинку (не обов’язково);
Сервіс обліку та управління камерами надає перелік камер. Після обрання камери Оператор вказує: - дані користувача:
- прізвище;
- ім’я;
- по-батькові4
- телефон;
- email;
- параметри замовлення:
- дата відео;
- час початку контенту;
- час закінчення контенту.
Після заповнення необхідних даних Оператор ініціює створення замовлення. Вказані Оператором дані направляються до Сервісу обліку та управління замовленнями перевіряє на повноту та коректність заповнені дані. У випадку, коли дані заповнено некоректно, Сервіс формує відповідь про помилку даних та інформує Оператора. У випадку, коли дані коректні, Сервіс направляє команду на створення замовлення до БД Замовлення з даними замовлення. БД записує замовлення, та в результаті виконання операції запису, повертає до Сервісу обліку та управління замовленнями підтвердження створення замовлення, номер замовлення та статус замовлення. Сервіс обліку та управління замовленнями формує підтвердження створення замовлення та інформує Оператора.
2.3.5. Сервіс обміну з ІАС «Майно»
Сервіс обміну з ІАС «Майно» представляє собою набір програмних інтерфейсів та забезпечує можливість обміну даними з ІАС «Майно» в частині передачі даних про камери з метою подальшого відображення камер на карті міста.
Рисунок 15. Процес передачі даних про камери до ІАС «Майно»
В рамках регламенту обміну даними про камери з ІАС «Майно», Сервіс обміну та управління камерами формує пакет даних про камери. По факту формування, сформовані дані передаються від Сервісу обліку та управління камерами до Сервісу обміну з ІАС «Майно», який направляє пакети даних до ІАС «Майно». В ІАС «Майно» відбувається збереження отриманих даних, та в рамках відповіді надається підтвердження отримання даних до Сервісу обміну з ІАС «Майно».
Інформація про камери, що передається до ІАС «Майно», відповідає Таблиця 4. Структура даних сутності Камера.
2.3.6. Сервіс адміністрування
Сервіс адміністрування представляє собою набір програмних інтерфейсів та забезпечує можливість здійснення пошуку операторів, створення, перегляду, редагування та логічного видалення операторів (далі – користувач Системи); облік та управління довідниками.
2.3.6.1. Мікросервіс управління користувачами.
В рамках Мікросервісу управління Адміністратор може виконувати наступні функції: - пошук даних користувачів Системи в БД; - читання даних користувачів Системи з БД; - запис даних користувача Системи до БД: запис, редагування¸ логічне видалення. В рамках пошукового запиту даних про користувача Системи, Адміністратор вказує наступні дані: - прізвище; - ім’я; - по-батькові. Мікросервіс управління користувачами отримує пошукові дані та направляє їх до БД користувачів. В рамках БД здійснюється пошук користувачів Системи за вказаними параметрами. В результаті успішного пошуку БД повертає до Мікросервісу управління користувачами наступні дані: - прізвище; - ім’я; - по-батькові; - роль. Мікросервіс управління користувачами формує відповідь з отриманими даними та надає відповідь з даними Адміністратору. В рамках отриманої відповіді з даними користувача, Адміністратор може виконувати наступні операції: - перегляд даних користувача Системи; - редагування даних користувача Системи; - логічне видалення користувача Системи. В рамках редагування Адміністратор може змінити дані користувача Системи, а також активувати/деактивувати користувача (див. Таблиця 5). Атрибути користувача наведено в Таблиця 5: Таблиця 5. Атрибути користувача Системи
Назва атрибуту | Тип даних | Обов’язковий / необов’язковий | Коментарі |
Особисті дані | |||
Прізвище | VARCHAR | Обов’язковий | |
Ім’я | VARCHAR | Обов’язковий | |
По батькові | VARCHAR | Обов’язковий | |
Організація | VARCHAR | Обов’язковий | |
Роль | VARCHAR | Обов’язковий | |
Контактні дані | |||
Телефон | INT | Обов’язковий | |
Е-mail | VARCHAR | Обов’язковий | |
Параметри користувача | |||
Статус | Boolean | Обов’язковий | Активний/Неактивний |
Адміністратор в рамках Мікросервісу управління користувачами може створювати користувачів Системи. Дані, які заповнюються при створенні, наведено в Таблиця 5. Процес створення наведено на Рисунок 16:
Рисунок 16. Процес створення користувача Адміністратором
Адміністратор вводить дані користувача Системи та ініціює запис введених даних. Мікросервіс управління користувачами виконує перевірку введених даних на повноту та коректність. У випадку, коли Адміністратор заповнив дані не в повному об’ємі або вказав некоректні дані, Мікросервіс управління користувачами формує повідомлення про помилку та інформує Адміністратора. У випадку, коли дані успішно пройшли перевірку, Мікросервіс управління користувачами ініціює запис до БД Користувачі з даними користувача. В БД виконується запис нового користувача Системи. БД надає Мікросервісу управління користувачами підтвердження створення запису. Мікросервіс управління користувачами формує повідомлення про успішне виконання операції створення користувача Системи та інформує Адміністратора.
Приклад форми створення користувача відображено на Рисунок 17:
Рисунок 17. Форма створення користувача
2.3.6.2. Мікросервіс управління довідниками
В рамках Мікросервісу управління довідниками Адміністратор може виконувати наступні операції з довідниками: - Створення запису довідника; - Перегляд довідника; - Редагування довідника. Первинні довідники та їх значення, що створені в Системі, наведено Таблиця 6. Довідник «Статуси» та Таблиця 7. Довідник «Типи камер» в відповідно. Таблиця 6. Довідник «Статуси»
Код | Значення | Опис |
1 | Відмова | Статус замовлення, яке не може бути виконане. Статус встановлює Оператор. Разом зі статусом вказується причина відмови. |
2 | У роботі | Статус замовлення, яке взято в роботу Оператором. |
3 | Виконано | Статус замовлення, для якого є результат у вигляді посилання на зовнішній файл з відео-контентом. |
Таблиця 7. Довідник «Типи камер»
Код | Значення |
1 | Оглядова Smart камера |
2 | Панорамна |
3 | Роботизована |
4 | Розпізнання обличчя |
5 | Розпізнання номерів |
В рамках перегляду довідника, Мікросервіс управління довідниками виконує обробку даних з БД Довідники, та відображає Адміністратору.
Рисунок 18. Процес створення довідника Адміністратором
Для створення значення довідника, Адміністратор обирає довідник, вводить назву та код значення, та ініціює запис. Мікросервіс управління довідниками виконує перевірку введених даних на повноту та коректність. У випадку, коли Адміністратор заповнив дані не в повному об’ємі або вказав некоректні дані, Мікросервіс управління довідниками формує повідомлення про помилку та інформує Адміністратора. У випадку, коли дані успішно пройшли перевірку, Мікросервіс управління довідниками ініціює запис до БД Довідники з вказаними даними. В БД виконується запис нового значення до відповідного довідника. БД надає Мікросервісу управління довідниками підтвердження створення запису. Мікросервіс формує повідомлення про успішне виконання операції створення запису в довідник та інформує Адміністратора про успішне виконання операції.
Приклад форми створення запису довідника відображено на Рисунок 19:
Рисунок 19. Форма створення запису довідника