Технічний дизайн рішення

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Контейнерна діаграма

На даній діаграмі зображено залучені для реалізації вимог сервіси платформи та взаємодію між ними.

2. Залучені сервіси та їх призначення в рамках дизайну рішення

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

Компонент	Службова назва	Призначення
Регламент реєстру	registry-regulation	Налаштування шаблонів для відправки повідомлень за каналами зв’язку
Пайплайн публікації регламенту	jenkins	Публікація змін до шаблонів повідомлень до цільового оточення реєстру
Утиліта публікації шаблонів	notification-template-publisher	Підготовка та завантаження шаблонів повідомлень з репозиторію регламенту в окреме сховище шаблонів для використання в рамках виконання сценаріїв
Інтерфейс адміністрування платформи	control-plane-console	Внесення налаштувань доступних каналів зв’язку для цільового оточення реєстру
Пайплайн створення реєстру	control-plane-jenkins	Застосування налаштувань каналів зв’язку до цільового оточення реєстру
Сервіс управління користувачами та доступом	keycloak	Отримання атрибутів користувачів за ідентифікатором (РНОКПП)
Кабінет громадянина	citizen-portal	Перегляд in-app повідомлень в inbox Кабінету Громадянина
Сервіс виконання бізнес-процесів	bpms	Формування та публікація події про необхідність відправки повідомлення користувачам у процесі виконання бізнес-процесу
Сервіс нотифікацій користувачів	notification-service	Реагування на події про необхідність відправки повідомлення користувачам шляхом генерації повідомлення на базі вказаного шаблону та вхідних даних з послідуючою відправкою в залежності від вказаного та попередньо налаштованого каналу зв’язку. Управління шаблонами повідомлень.
Сервіс управління налаштуваннями користувачів	user-settings-service-api	Отримання налаштувань каналів зв’язку обраних користувачами для отримання повідомлень
Платформенний поштовий сервер	platform-mail-server	Поштовий сервер, який розповсюджується разом з платформою для сумісного використання реєстрами у якості опції за замовчуванням
Зовнішній поштовий сервер	external-mail-server	Поштовий сервер за вибором адміністратора реєстру у разі особливих вимог до відправки поштових повідомлень
Сервіс нотифікацій Дія	diia-notification-service	Відправки push-нотифікацій користувачам мобільного додатку Дія
Розподілена реляційна база даних Citus	citus-master	Довготривале збереження шаблонів повідомлень на цільовому оточенні реєстру. Збереження in-app повідомлень користувачів.
Розподілений брокер повідомлень Kafka	kafka	Обмін повідомленнями між компонентами системи управління реєстром

Компонент

Службова назва

Призначення

Регламент реєстру

registry-regulation

Налаштування шаблонів для відправки повідомлень за каналами зв’язку

Пайплайн публікації регламенту

jenkins

Публікація змін до шаблонів повідомлень до цільового оточення реєстру

Утиліта публікації шаблонів

notification-template-publisher

Підготовка та завантаження шаблонів повідомлень з репозиторію регламенту в окреме сховище шаблонів для використання в рамках виконання сценаріїв

Інтерфейс адміністрування платформи

control-plane-console

Внесення налаштувань доступних каналів зв’язку для цільового оточення реєстру

Пайплайн створення реєстру

control-plane-jenkins

Застосування налаштувань каналів зв’язку до цільового оточення реєстру

Сервіс управління користувачами та доступом

keycloak

Отримання атрибутів користувачів за ідентифікатором (РНОКПП)

Кабінет громадянина

citizen-portal

Перегляд in-app повідомлень в inbox Кабінету Громадянина

Сервіс виконання бізнес-процесів

bpms

Формування та публікація події про необхідність відправки повідомлення користувачам у процесі виконання бізнес-процесу

Сервіс нотифікацій користувачів

notification-service

Реагування на події про необхідність відправки повідомлення користувачам шляхом генерації повідомлення на базі вказаного шаблону та вхідних даних з послідуючою відправкою в залежності від вказаного та попередньо налаштованого каналу зв’язку. Управління шаблонами повідомлень.

Сервіс управління налаштуваннями користувачів

user-settings-service-api

Отримання налаштувань каналів зв’язку обраних користувачами для отримання повідомлень

Платформенний поштовий сервер

platform-mail-server

Поштовий сервер, який розповсюджується разом з платформою для сумісного використання реєстрами у якості опції за замовчуванням

Зовнішній поштовий сервер

external-mail-server

Поштовий сервер за вибором адміністратора реєстру у разі особливих вимог до відправки поштових повідомлень

Сервіс нотифікацій Дія

diia-notification-service

Відправки push-нотифікацій користувачам мобільного додатку Дія

Розподілена реляційна база даних Citus

citus-master

Довготривале збереження шаблонів повідомлень на цільовому оточенні реєстру. Збереження in-app повідомлень користувачів.

Розподілений брокер повідомлень Kafka

kafka

Обмін повідомленнями між компонентами системи управління реєстром

3. Налаштування політик міжсервісної взаємодії

Для коректної роботи підсистеми нотифікацій, мають бути налаштовані відповідні мережеві політики NetworkPolicy, які дозволяють взаємодію для наступних компонентів:

kong → notification-service
bpms → kafka
notification-service → kafka
notification-service → keycloak
notification-service → user-settings-service-api
notification-service → citus-master
notification-service → kafka-schema-registry
notification-service → platform-mail-server

В залежності від обраної конфігурації на етапі створення/редагування налаштувань реєстру, буде автоматично створено ServiceEntry для налаштування доступу до зовнішніх сервісів на рівні Istio Service Mesh:

notification-service → external-mail-server
notification-service → diia-notification-service

4. Kafka-топіки запитів на відправку повідомлень користувачам

Наразі, за обслуговування запитів на відправлення повідомлень користувачам відповідають наступні Kafka-топіки, сегреговані за призначенням, вимогами до масштабування та контролю навантаження на downstream-сервіси:

Службова назва

Опис

user-notifications

Публікація та обробка системних запитів на відправлення повідомлень користувачам. Реалізує асинхронну взаємодію між сервісами реєстру та Сервісом відправки повідомлень користувачам

user-notifications.DLT

Публікація запитів на відправлення повідомлень користувачам, які не вдалося опрацювати Сервісом відправки повідомлень користувачам

email-notifications

Публікація та обробка запитів на відправлення поштових повідомлень користувачам через платформенний або зовнішній SMTP-сервер

email-notifications.DLT

Публікація запитів на відправлення поштових повідомлень користувачам, які не вдалося опрацювати

diia-notifications

Публікація та обробка запитів на відправлення push-повідомлень користувачам у мобільний застосунок Дія

diia-notifications.DLT

Публікація запитів на відправлення push-повідомлень користувачам у мобільний застосунок Дія, які не вдалося опрацювати

inbox-notifications

Публікація та обробка запитів на відправлення повідомлень користувачам у Кабінет Громадянина

inbox-notifications.DLT

Публікація запитів на відправлення повідомлень користувачам у Кабінет Громадянина, які не вдалося опрацювати

4.1. Публікація та обробка системних запитів на відправлення повідомлень

Перелік Kafka-топіків:

user-notifications
user-notifications.DLT

Канонічний вигляд структури повідомлення

{
  "context": {
    "system": "Low-code Platform",
    "application": "<bpms.app.name>",
    "businessProcess": "<optional>",
    "businessProcessDefinitionId": "<optional>",
    "businessProcessInstanceId": "<optional>",
    "businessActivity": "<optional>",
    "businessActivityInstanceId": "<optional>"
  },
  "notification": {
    "templateName": "<notification template unique name>",
    "ignoreChannelPreferences": "<true|false (default: false) - ignore whether channel is active or not - used for OTP verification, etc. >"
  },
  "recipients": [
    {
      "id": "<Ідентифікатор користувача>",
      "channels": [
        {
          "channel": "diia",
          "rnokpp": "<ІПН користувача>"
        },
        {
          "channel": "email",
          "email": "<Email користувача>"
        }
      ],
      "parameters": [
        {
            "key": "<key>",
            "value": "<value>"
        }
      ]
    }
  ]
}

4.2. Публікація та обробка запитів на відправлення повідомлень користувачам у Кабінет Громадянина

Перелік Kafka-топіків:

inbox-notifications
inbox-notifications.DLT

Канонічний вигляд структури повідомлення

{
  "context": {
    "system": "Low-code Platform",
    "application": "<bpms.app.name>",
    "businessProcess": "<optional>",
    "businessProcessDefinitionId": "<optional>",
    "businessProcessInstanceId": "<optional>",
    "businessActivity": "<optional>",
    "businessActivityInstanceId": "<optional>"
  },
  "notification": {
    "subject": "<notification subject>",
    "message": "<notification message>"
  },
  "recipient": {
    "id": "<Ідентифікатор користувача>"
  }
}

4.3. Публікація та обробка запитів на відправлення поштових повідомлень

Перелік Kafka-топіків:

email-notifications
email-notifications.DLT

Канонічний вигляд структури повідомлення

{
  "context": {
    "system": "Low-code Platform",
    "application": "<bpms.app.name>",
    "businessProcess": "<optional>",
    "businessProcessDefinitionId": "<optional>",
    "businessProcessInstanceId": "<optional>",
    "businessActivity": "<optional>",
    "businessActivityInstanceId": "<optional>"
  },
  "notification": {
    "subject": "<notification subject>",
    "message": "<notification message>"
  },
  "recipient": {
    "id": "<Ідентифікатор користувача - optional>",
    "email": "<Email користувача>"
  }
}

4.4. Публікація та обробка запитів на відправлення push-повідомлень у мобільний застосунок Дія

Перелік Kafka-топіків:

diia-notifications
diia-notifications.DLT

Канонічний вигляд структури повідомлення

{
  "context": {
    "system": "Low-code Platform",
    "application": "<bpms.app.name>",
    "businessProcess": "<optional>",
    "businessProcessDefinitionId": "<optional>",
    "businessProcessInstanceId": "<optional>",
    "businessActivity": "<optional>",
    "businessActivityInstanceId": "<optional>"
  },
  "notification": {
    "templateName": "<template name>",
    "externalTemplateId": "<external template id>"
  },
  "recipient": {
    "id": "<Ідентифікатор користувача - optional>",
    "rnokpp": "<ІПН користувача>",
    "parameters": [
      {
        "key": "<key>",
        "value": "<value>"
      }
    ]
  }
}

4.5. Загальні налаштування Kafka-топіків підсистеми нотифікацій

4.5.1. Налаштування цільових топіків запитів на відправку повідомлень

Властивість	Значення	Опис
num-partitions	1	Кількість розділів в рамках топіку для збереження повідомлень
replication-factor	1	Кількість реплік цільового топіка
retention-policy-in-days	7	Кількість днів збереження повідомлення в Kafka

Властивість

Значення

Опис

num-partitions

Кількість розділів в рамках топіку для збереження повідомлень

replication-factor

Кількість реплік цільового топіка

retention-policy-in-days

Кількість днів збереження повідомлення в Kafka

4.5.2. Налаштування Dead-Letter-Queue топіків запитів на відправку повідомлень, які не вдалося опрацювати

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

Властивість	Значення	Опис
num-partitions	1	Кількість розділів в рамках топіку для збереження повідомлень
replication-factor	1	Кількість реплік цільового топіка
retention-policy-in-days	7	Кількість днів збереження повідомлення в Kafka

Властивість

Значення

Опис

num-partitions

Кількість розділів в рамках топіку для збереження повідомлень

replication-factor

Кількість реплік цільового топіка

retention-policy-in-days

Кількість днів збереження повідомлення в Kafka

Перегляд та моніторинг подій, які не вдалося опрацювати, можливий через окремий веб-інтерфейс kafka-ui.

У разі необхідності відправлення подій адміністратором на повторне опрацювання, розглядається опція побудови окремого службового процесу на базі Kafka Connect, який буде переносити події з Dead-Letter-Queue у цільовий топік.