MessageGateway

MessagesGateway
Шлюз верифікації користувачів 

Функціональний дизайн та опис бізнес процесів
(Технічне завдання)
07.02.2019р. 



































Київ, 2019 

Інформація про документ: 

 
Історія змін: 

Зміст
Загальний огляд……………………………………………………………………..3
Загальні бізнес-вимоги(BR)…………………………………………………….4
Ризики та загрози.....................................................................7
1.Авторизація…………………………………………………………………………8
2.Головний екран……………………………………………………………………8
2.1.Екран типи операторів……………………………………………………..8
2.2.Екран оператори……………………………………………………………….9
2.3.Екран конфігурація системи…………………………………………….10
2.4.Екран конфігурація ключів………………………………………………11
3.Технології,що будуть використані при розробці……………….12
3.1. Визначення компонентів ……………………………………………….12
3.2. Графічний опис роботи компонентів додатку (BPMN)….12
3.3. Структура бази даних (PostgreSQL)………………………………..16
3.4. Структура даних, що зберігаються в Redis…………………….17
3.5. Структура даних ,що зберігаються в RabbiMQ………………17
Критерій прийому результатів робіт…………………………………….18 







Загальний огляд 
Overview.
Messages Gateway є частиною програмного комплексу, що відповідає за пріоритизацію відправки повідомлень користувачам сервісу ehealth за допомогою SMS(Vodafone,Lifecell), Viber, Telegram, Email або за допомогою IP телефонії.
Goals
1.Забезпечити зручний механізм пріоритизації сервісів відправки повідомлень користувачам.
2.Розробити інтерфейс для вибору методів інформування з врахуванням встановлених пріоритетів, забезпечити можливість адміністрування.
3.Розробити серверну частину системи, а також забезпечити збір статистики по операціях клієнтів.
UI Requirements
1.Корпоративними кольорами системи вважаються - голубий, помаранчевий та синій.
2.Веб додаток розробляється з розширенням екрану від 1024px.
3.Назвою додатку вважається MessagesGateway. 



















Загальні бізнес вимоги (BR) 

Ризики та загрози
Станом на 08.02.2019 існують наступні загрози та обмеження:

Description.
1.Авторизація користувачів системи відбувається через екран авторизації
Умовою потрапляння на екран авторизації вважається є перехід за адресою або ознака того, що в юзера немає дійсного токена на сервері і йому потрібно авторизуватися для переходу в адміністративну панель 
1.1.Кнопка "Увійти за допомогою EHEALTH" є єдиним елементом екрану авторизації.
При натисканні кнопки увійти відбувається переадресація на систему авторизації Ehealth для вводу логіну та пароля. Після успішної авторизації користувач переадресовуєтеся у адміністративну панель.
У випадку неуспішної авторизації юзер отримує повідомлення про помилку. 
2.При успішній авторизації юзер потрапляє на головний екран адміністративної панелі. 
Головний екран адміністративної панелі має наступне наповнення: 
-Лого
-СайдБар меню з пунктами. При натисканні кожного пункту переадресовує користувача на відповідне меню:
•Типи операторів (Список доступних методів зв'язку з користувачами )
•Оператори
•Конфігурація системи (Налаштування системи )
•Конфігурація ключів
•Вийти (Вихід із системи на екран Авторизації) 
А також текст "Щоб розпочати роботу виберіть пункт в меню" 


2.1.Екран типи операторів (список доступних методів зв'язку з користувачами) надісланий від серверу за допомогою відповідного сервісу. 
Кожен з елементів має: 
-Елемент для задання пріоритету. Зміна пріоритету відбувається шляхом перетягування елементів drag and drop'ом. В момент фіксації методу на новому місці оновлюються номери пріоритету всіх інших методів в залежності від положення в списку. 
-Кнопку для видалення(смітник)
-Назву типу активності(месенджер, смс-повідомлення, IP телефонія)
-Прапорець ,що дозволяє включити/виключити метод зв'язку
-Номер пріоритету (використовується сервером для пріоритизації методів зв'язку з користувачами ) 
Також наявні кнопки: 
-Кнопка "Додати тип оператора"
-Кнопка "Зберегти" 

2.1.1.Кнопка "Додати тип оператора " 
При натисканні кнопки "Додати тип оператора" Користувач повинен обрати назву для типу створюваного нового методу. 
Передбачається використання наступних протоколів: 
1) SMTP 
2) Telegram
3) Viber
4) Lifecell IP Telephony
5) Lifecell SMS
6) Vodafone SMS
А також кнопки "Зберегти", "Повернутись до списку операторів"
Після натискання "Зберегти" відбувається збереження нового типу та повернення на сторінку типів операторів.
При натисканні "Повернутись до списку операторів" відбувається повернення на сторінку типів операторів. 

2.2. Екран "Оператори" (методу зв'язку). 
Користувач потрапляє на даний екран при наявності відповідних прав та валідного токена.
Відображається список існуючих операторів, при кліку на зону будь-якого з них відбувається перехід на сторінку "Деталі оператора" 
При кліку на кнопку "Додати оператора" відбувається перехід на pop-up з налаштуваннями для створення, де потрібно обрати тип оператора з існуючих та відповідний йому протокол. 
При подальшому натисканні кнопки "Додати" відбувається перехід на екран створення оператора. 
2.2.1. Екран "Деталі оператора"
Список текстових полів надсилається сервером в залежності від типу вибраного створюваного сервісу. Сервер надсилає кількість стандартних полів для певного типу, а також key, value до кожного поля. 
Стандартними полями для всіх типів методів є:
1) Name Назва
2) Price Вартість одного повідомлення. В копійках (коп.)
3) Limit Гранична кількість повідомлень за 1с 
Користувачу доступні наступні активні елементи:
Прапорець "active" - дозволяє включити/виключити певного оператора зі списку.
Кнопка "Зберегти" - відправляє дані всіх полів на сервер за допомогою виклику відповідного сервісу. Переадресовує користувача на екран Пріоритети сервісів.
Кнопка "Повернутись до списку операторів" - повертає на екран "Оператори" 


2.2.2.Екран створення оператора.
В pop-up "Оберіть налаштування для створення" міститься два поля, що підлягають обранню - тип оператора та протокол.
Після обрання і натискання кнопки "ЗБЕРЕГТИ" відбувається перехід на екран "Створення оператора". 
Необхідно заповнити поля надіслані сервером. Набір полів для заповнення прямо залежить від обраного протоколу.
Для збереження нового оператора на екрані "Створення оператора" необхідно натиснути кнопку "ЗБЕРЕГТИ" 

2.3.Екран Конфігурація Системи. 
Список текстових полів Конфігурації надсилається сервером. Сервер надсилає кількість полів для налаштувань, а також key, value до кожного поля. 
Для кожної конфігурації можна налаштувати використання чи не використання автоматичної пріоритизації, зробивши відповідну відмітку в полі automatic_prioritization. 
Користувачу доступна кнопка: 
"Зберегти"- відправляє дані всіх полів на сервер за допомогою виклику відповідного сервісу. 




2.3.1. "Автоматична пріоритизація" 
При увімкненні даної опції для обраної конфігурації відбувається виклик сервісу, що встановлює на сервері Автоматичний вибір методів зв'язку з користувачем за найменшою ціною. 
Якщо дана опція увімкнута ,то пріоритизація відбувається по вартості одного повідомлення.
Якщо дана опція вимкнена , то пріоритизація відбувається згідно з пріоритетами, виставленими на сторінці Типи операторів 
Приклади застосування

• Пріоритет по вартості однієї SMS, наприклад в адмін. панелі проставлені наступні значення вартості однієї SMS по оператору:
• Lifecell - 18 коп.
• Viber - 17 коп.
• Telegram - 0 коп.

Тоді список сервісів для відправки буде наступним: [Telegram, Viber,Lifecell]. Тобто спочатку ми намагаємося відправити юзеру повідомлення в Telegram, у випадку якщо даний номер не зареєстрований або у юзера відсутній інтернет, ми намагаємося відправити повідомлення у Viber, у випадку якщо даний номер не зареєстрований або у юзера відсутній інтернет, ми відправляємо йому SMS повідомлення через оператора Lifecell.

• Пріоритет по сервісам, наприклад в адмін. панелі проставлені наступна пріоритетність операторів:
• Lifecell - 3 (третій пріоритет)
• Viber - 1 (перший пріоритет)
• Telegram - 2 (другий пріоритет)

То список сервісів для відправки буде наступним: [Viber, Telegram, Lifecell]. Тобто спочатку ми намагаємося відправити юзеру повідомлення у Viber, у випадку якщо даний номер не зареєстрований або у юзера відсутній інтернет, ми намагаємося відправити повідомлення на Telegram, у випадку якщо даний номер не зареєстрований або у юзера відсутній інтернет, ми відправляємо йому SMS повідомлення через оператора Lifecell. 
2.4. Екран "Конфігурація ключів" На даному екрані відображаються конфігурації ключів(пари user+key), надіслані від сервера . 
Пара ключів user+key генерується для перевірки достовірності запиту від адмін.частини.
В хедер http запитів додається ключ Authorization зі значенням "Bearer id:key",але ключ key шифрується за допомогою sha256 
Генерація нових ключів відбувається за допомогою кнопки "ЗГЕНЕРУВАТИ НОВИЙ КЛЮЧ".
Новий ключ автоматично додається до списку зі статусом "Активний". 
Будь-який з ключів можна видалити натиснувши на кнопку-смітник або активувати/деактивувати натиснувши на відповідну кнопку. 
3.Технології,що будуть використані при розробці

3.1.Визначення компонентів 
MessagesGateway.API — це Umbrella додаток, що складається з декількох пов'язаних між собою додатків:

• Ehealth - центральний компонент системи ;
• MessagesGateway.admin.web - адмін панель додатку ;
• MessagesGateway - компонент додатку який хендлить запити з центрального компоненту системи Ehealth и от MessagesGateway.admin.web. В даному компоненті відбувається валідація повідомлення, присвоєння приорітетів, присвоєння унікального ідентифікатора повідомлення, відправка повідомлення в чергу та створення запису в Redis ;
• Redis - база даних для тимчасового зберігання інформації ;
• DBAgent - компонент для зв'язку додатку з базою даних ;
• MessagesRouter — компонент який згідно з приорітетами надсилає повідомлення на протоколи,опрацьовує стан повідомлення і відправляє відповідь на центральний компонент системи ;
• SMPP_Protocol - протокол відправки коротких повідомлень на оператора ;
• SMTP_Protocol - протокол для відправки Email повідомлень ;
• IPTel_Protocol – протокол для роботи з IP телефонією ;
• Protocols - протокол для роботи с API Telegram, API Viber, з операторами зв'язку та ін.
• Elasticsearch – додаток для роботи з логами

3.2.  Графічний опис роботи компонентів додатку (BPMN):
Точка взаємодії компонента з ЦК:
 
Загальний процес:

MessagesRouter:

Messages Router.Queues:
 
Опис Callback повідомлень на ЦК системи

1. При будь-якому кінцевому статусі відправки повідомлення на callback URL ЦК системи відправляється повідомлення зі статусом відправки
2. У відповідь на дане повідомлення система буде очікувати json вигляду Status: Ok и HTTP Status200(201).

BPMN Візуалізація дій в адміністративній частині:  



3.3. Структура бази даних (PostgreSQL) 

operator (operator_name)
Інформація щодо оператора/месенджера

contact
Тип контакту(email, номер телефону)

operator_type
Спосіб відправки повідомлень

3.4. Структура даних,що зберігаються в Redis

3.5. Структура даних ,що зберігаються в RabbiMQ

Критерій прийому результатів робіт 
 
Даний документ є одним з головних документів проекту. 
Розробка сервісів з боку Skywell буде побудована, ґрунтуючись на описі процесів і функцій кожного розділу і екрану. 
По закінченню етапу розробки, загальні частини документу можуть бути використані департаментом тестування Skywell для внутрішнього тестування якості програмного продукту і відповідності заявленим раніше вимогам і функціям роботи. За підсумками внутрішнього тестування невідповідності будуть усунуті. 
Результатом роботи є програмний продукт – бекенд сервіси та адмін панель (фронт-енд). 
Критеріями прийому Замовником (ehealth) програмного продукту є: 

1. Відсутність критичних або суттєвих помилок у роботі програми. Тобто таких помилок, що аварійно завершують роботу сервісів або не дозволяють виконати ту чи іншу заявлену функцію. У цьому випадку, діагностування помилки повинно супроводжуватися підтвердженням наявності помилки на стороні Skywell Software, а не частини яка лежить поза межами компетенції Skywell Software. 
2. Повна відповідність фактичної роботи додатків заявленим процесам і функцій даного документа - відповідність ТЗ по наповненню.  

У разі, якщо в ті чи інші Процеси або функції роботи, які вказані в даному документі, вносилися зміни вже після затвердження ТЗ - всі зміни повинні бути відображені в ТЗ з нарощуванням версії і узгодженням з усіма сторонами проекту. Прийом програмного продукту виконується за останньою версією Технічного Завдання. 

1. Всі приховані або невиявлені неточності роботи системи, які не були виявлені чи підтверджені в ході тестових робіт – можуть бути усунені в період після здачі проекту, що відображається в договірних відносинах.