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

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

1. Загальний опис

За реалізацію вимог по формуванню та відправленню повідомлень користувачам відповідає "Сервіс повідомлень користувачів".

Інтерфейсом для зовнішньої взаємодії з сервісом виступає окремий Kafka-топік "user-notifications", а основою рішення є реагування та обробка подій-запитів на генерацію повідомлень з використанням FreeMarker-шаблонів, попередньо завантажених у сховище та їх послідуюча відправка згідно налаштувань користувача у Kafka-топіки, які відповідають за окремі канали зв’язку.

У разі, якщо подію-запит на відправку повідомлення через "user-notifications" топік не вдалося обробити, система проводить N спроб згідно поточної конфігурації і за відсутності результату перенаправляє повідомлення в окремий службовий топік "user-notifications.DLT".

2. Компонентна діаграма

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

3. Компоненти та їх призначення

Компонент	Бібліотека	Призначення
Notification Event Subscriber	-	Обробка системних запитів на відправлення повідомлень користувачам Логування деталей у разі невдалої спроби опрацювання запиту. Публікація запитів, які не вдалося опрацювати у окрему чергу повідомлень для аналізу.
Notification Service	-	Оркестрація процесу обробки запиту на відправлення повідомлень. Завантаження налаштувань користувачів та їх даних, необхідних для відправлення. Формування переліку каналів для яких необхідно відправити повідомлення.
Notification Template Service	-	Збереження змін до шаблонів повідомлень. Отримання шаблону повідомлення для каналу зв’язку.
Channel Notification Validators	-	Валідація запиту на відправку повідомлення згідно особливостей каналу зв’язку
Channel Notification Producers	-	Формування запиту на відправлення повідомлення для окремого каналу зв’язку на базі шаблону
Channel Notification Publishers	-	Публікація запитів на відправлення повідомлень для окремого каналу зв’язку
Channel Notification Subscribers	-	Обробка запитів на відправлення повідомлень для окремого каналу зв’язку. Публікація запитів, які не вдалося опрацювати у окрему чергу канала для подальшої обробки
Inbox Notification Service	-	Збереження in-app повідомлень для користувача. Отримання переліку in-app повідомлень користувача. Підтвердження перегляду in-app повідомлення користувачем
User Settings Feign Client	ddm-user-settings-client	Отримання налаштувань каналів зв’язку для користувача
Diia Notification Service	ddm-diia-client	Відправлення push-повідомлення користувачу
Diia Notification Template Service	ddm-diia-client	Реєстрація шаблону повідомлення для послідуючого використання при відправленні push-повідомлення
Audit Service	ddm-audit-starter	Фіксація події аудиту в журнал
Idm Service	ddm-idm-client	Отримання атрибутів користувача за ідентифікатором

Компонент

Бібліотека

Призначення

Notification Event Subscriber

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

Логування деталей у разі невдалої спроби опрацювання запиту.

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

Notification Service

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

Завантаження налаштувань користувачів та їх даних, необхідних для відправлення.

Формування переліку каналів для яких необхідно відправити повідомлення.

Notification Template Service

Збереження змін до шаблонів повідомлень.

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

Channel Notification Validators

Валідація запиту на відправку повідомлення згідно особливостей каналу зв’язку

Channel Notification Producers

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

Channel Notification Publishers

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

Channel Notification Subscribers

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

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

Inbox Notification Service

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

Отримання переліку in-app повідомлень користувача.

Підтвердження перегляду in-app повідомлення користувачем

User Settings Feign Client

ddm-user-settings-client

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

Diia Notification Service

ddm-diia-client

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

Diia Notification Template Service

ddm-diia-client

Реєстрація шаблону повідомлення для послідуючого використання при відправленні push-повідомлення

Audit Service

ddm-audit-starter

Фіксація події аудиту в журнал

Idm Service

ddm-idm-client

Отримання атрибутів користувача за ідентифікатором

4. Взаємодія компонентів в рамках реалізації сценаріїв

4.1. Отримання in-app повідомлень та підтвердження перегляду користувачем

4.2. Відправлення повідомлень

4.2.1. Загальний сценарій обробки повідомлень

Зображення 1. Загальний сценарій обробки повідомлень kafka-топіком user-notifications

4.2.2. Обробка запиту на відправлення поштового повідомлення

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

4.2.3. Обробка запиту на відправлення push-нотифікації в Дію

З детальною інформацією щодо взаємодії з сервісом нотифікація Дії можна ознайомитись у розділі API відправки push-нотифікацій у мобільний додаток "Дія".

Зображення 3. Обробка запитів на відправку push-нотифікацій користувачам у мобільний додаток Дія

4.2.4. Обробка запиту на відправлення in-app повідомлень у inbox користувача Кабінету Громадянина

5. Загальні налаштування сервісу

Приклад налаштувань сервісу для публікації подій через Kafka-топік (на прикладі використання ddm-starter-kafka бібліотеки)

data-platform:
  kafka:
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
      custom-config:
        "[enable.idempotence]": true
    topic-properties:
      creation:
        enabled: true
        timeout-in-seconds: 60
      retention:
        default-in-days: 7
        num-partitions: 1
        replication-factor: 1
    error-handler:
      initial-interval: 1500
      max-elapsed-time: 6000
      multiplier: 2
    topics:
      "<topic-name>": "<topic-name>"

Приклад налаштувань сервісу для отримання повідомлень через Kafka-топік (на прикладі використання ddm-starter-kafka бібліотеки)

data-platform:
   kafka:
     consumer:
       group-id: <consumer-group>
       key-deserializer: org.springframework.kafka.support.serializer.ErrorHandlingDeserializer
       value-deserializer: org.springframework.kafka.support.serialize.ErrorHandlingDeserializer
       custom-config:
         "[allow.auto.create.topics]": false
         "[retry.backoff.ms]": 10000
     topics:
       "<topic-name>": "<topic-name>"
     error-handler:
       initial-interval: 1500
       max-elapsed-time: 6000
       multiplier: 2

Існує необхідність реалізації автоматичного створення Kafka-топіків "<topic-name>.DLT" в рамках ddm-starter-kafka бібліотеки (StartupKafkaTopicsCreator) для коректного відпрацювання DeadLetterPublishingRecoverer стратегії при неможливості обробки повідомлення.

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

notifications:
  email:
    host: smtp.gmail.com
    port: 587
    username: <username>
    password: <password>
    properties:
      mail:
        transport:
          protocol: smtp
        smtp:
          auth: true
          starttls:
            enable: true
  diia:
    url: https://api2t.diia.gov.ua/
    partner:
      token: <partner-token>