Проміжні дані бізнес-процесів

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

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

1. Опис складових проміжних даних БП

Проміжні дані БП - це логічна група даних, яка належить окремому екземпляру бізнес-процесу та складається з наступних складових:

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

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

2. Сценарії використання проміжних даних

Зберігання та використання проміжних даних БП
Обмін проміжними даними БП при міжсервісній взаємодії
Обмін проміжними даними БП при міжпроцесній взаємодії
Видалення проміжних даних БП при завершенні виконання бізнес-процесів

3. Базові принципи

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

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

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

Для збереження та обміну проміжними даними бізнес-процесів використовуються два типи сховищ:

Redis: Hash-структура з сегрегацією даних за keyspaces
Ceph: "lowcode-file-storage" бакет для тимчасового збереження документів

4.1. Компоненти системи та їх призначення в рамках дизайну рішення

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

Компонент	Службова назва	Сценарії використання
Сервіс виконання бізнес-процесів	bpms	- Збереження та читання даних та підпису користувача, отриманих через UI-форми задач бізнес-процесів. - Збереження похідних даних та системного підпису. - Збереження та читання пейлоадів повідомлень, сформованих при міжпроцесній взаємодії. - Видалення тимчасових даних при завершенні виконання бізнес-процесів.
Сервіс управління задачами користувачів	user-task-management	- Збереження даних користувача та підпису, отриманих у процесі виконання задач бізнес-процесів. - Читання даних користувача, отриманих у процесі виконання задач бізнес-процесів
Сервіс управління процесами користувачів	user-process-management	Збереження вхідних даних, отриманих від користувача через стартову UI-форму бізнес-процесу
Сервіс-шлюз для інтеграції з зовнішніми системами	bp-webservice-gateway	Збереження вхідних даних, необхідних для ініціювання бізнес-процесу у разі виклику зовнішніми системами
Сервіс цифрових документів	digital-documents	- Зберігання проміжних даних / документів на час виконання бізнес-процесів - Видалення проміжних даних / документів при завершенні виконання бізнес-процесів.
Сервіс обслуговування запитів на зміни даних реєстру	registry-rest-api	- Отримання первинних даних користувача з накладеним підписом. - Отримання підпису, згенерованого на похідні дані системою
Сервіс обслуговування запитів на генерацію витягів	excerpt-service-api	- Отримання первинних даних користувача з накладеним підписом. - Отримання підпису, згенерованого на похідні дані системою
Розподілене in-memory сховище даних	redis	Зберігання проміжних даних на час виконання бізнес-процесів
Розподілене об’єктне сховище даних	ceph	Зберігання проміжних даних / документів на час виконання бізнес-процесів

Компонент

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

Сценарії використання

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

bpms

- Збереження та читання даних та підпису користувача, отриманих через UI-форми задач бізнес-процесів.

- Збереження похідних даних та системного підпису.

- Збереження та читання пейлоадів повідомлень, сформованих при міжпроцесній взаємодії.

- Видалення тимчасових даних при завершенні виконання бізнес-процесів.

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

user-task-management

- Збереження даних користувача та підпису, отриманих у процесі виконання задач бізнес-процесів.

- Читання даних користувача, отриманих у процесі виконання задач бізнес-процесів

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

user-process-management

Збереження вхідних даних, отриманих від користувача через стартову UI-форму бізнес-процесу

Сервіс-шлюз для інтеграції з зовнішніми системами

bp-webservice-gateway

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

Сервіс цифрових документів

digital-documents

- Зберігання проміжних даних / документів на час виконання бізнес-процесів

- Видалення проміжних даних / документів при завершенні виконання бізнес-процесів.

Сервіс обслуговування запитів на зміни даних реєстру

registry-rest-api

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

- Отримання підпису, згенерованого на похідні дані системою

Сервіс обслуговування запитів на генерацію витягів

excerpt-service-api

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

- Отримання підпису, згенерованого на похідні дані системою

Розподілене in-memory сховище даних

redis

Зберігання проміжних даних на час виконання бізнес-процесів

Розподілене об’єктне сховище даних

ceph

Зберігання проміжних даних / документів на час виконання бізнес-процесів

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

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

bpms → redis
bpms → digital-documents
user-task-management → redis
user-process-management → redis
bp-webservice-gateway → redis
registry-rest-api → redis
excerpt-service-api → redis

Актуалізація та видалення застарілих політик мережевого доступу у разі необхідності проводити на N+1 оновленні версії Платформи.

4.3. Структурна діаграма компонентів системи

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

ddm-form-data-storage
ddm-file-storage
ddm-bpm-message-payload-storage

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

4.4. Генерація ключів для проміжних даних

Для збереження даних за допомогою Redis Hash-структури, використовується підхід сегрегації об’єктів через Keyspaces-префікси (<keyspace>:<original-key>):

bpm-form-submissions
bpm-message-payloads

На даному етапі, алгоритм генерації <original-key> залишається без змін для забезпечення коректності міграції даних при переході з Ceph на Redis.

Приклад паттерну ключа для даних задачі:

bpm-form-submissions:process/${processInstanceId}/task/{taskDefinitionKey}

Приклад паттерну ключа для даних тіла повідомлення міжпроцесної взаємодії:

bpm-message-payloads:process-definition/{processDefinitionKey}/start-message/{uuid}

4.5. Структура даних bpm-form-submissions keyspace

bpm-form-submissions

{
  "x-access-token": "...",
  "data": {
    ...
  },
  "signature": "..."
}

4.6. Структура даних bpm-message-payloads keyspace

bpm-message-payloads

{
  "data": {
    ...
  }
}

4.7. Автоматичне видалення проміжних даних бізнес-процесів

Система повинна проводити автоматичне видалення проміжних даних зі сховища по завершенню бізнес-процесів (переходу в стан COMPLETED або EXTERNALLY_TERMINATED), в рамках яких вони були отримані або породжені.

4.7.1. lowcode-file-storage Ceph-bucket

Файли, які були завантажені через UI-форми задач користувачами

4.7.2. bpm-form-submissions Redis keyspace

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

4.7.3. bpm-message-payloads Redis keyspace

Дані, які були породжені у результаті міжпроцесної взаємодії

5. Відмовостійке key-value сховище даних на базі Redis Sentinel

У якості key-value сховища проміжних даних БП використовується Redis, а відмовостійкість забезпечується за допомогою механізму Redis Sentinel.

Redis Sentinel є розподіленою системою, яка складається з N екземплярів Sentinel процесів, які взаємодіють один з одним.

Redis Sentinel має наступні особливості:

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

Redis Sentinel надає наступні можливості:

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

Детальну інформацію можно знайти в офіційній іехнічній документації Redis Sentinel.

5.1. Розгортання Redis Sentinel

Для автоматизації розгортання та управління Redis Sentinel сховищем використовується окремий Kubernetes-оператор Redis Operator by Spotahome.

Особливості розгортання:

Взаємодія з Redis Sentinel потребує аутентифікації клієнтів
Взаємодія з Redis потребує аутентифікації клієнтів
Обмін даними між Sentinel та Redis-екземплярами захищено за допомогою TLS
Розроблено 3 можливих конфігурації розгортання Redis Sentinel в залежності від вимог відмовостійкості та наявних ресурсів:
- Minimal
- Recommended
- CI/CD

5.2. Конфігурація Redis Sentinel

Налаштування	Значення	Опис
sentinel.replicas	3	Кількість екземплярів Sentinel-процесів
redis.replicas	2	Кількість екземплярів Redis-реплік
sentinel.quorum	2	Кількість Sentinel-процесів, яка необхідна для підтвердження непрацездатності / недоступності Redis-мастера
sentinel.customConfig."down-after-milliseconds"	60000	Час в мілісекундах, протягом якого екземпляр Redis має бути недоступним, щоб Sentinel почав вважати його непрацездатним
sentinel.customConfig."failover-timeout"	180000	Час в мілісекундах, який використовується у якості затримки при підтвердженні недоступності Redis-мастера
sentinel.customConfig."parallel-syncs"	1	Кількість Redis-реплік, які є одночасно недоступними у процесі реконфігурації на використання нового Redis-мастера у разі автоматичного відновлення
sentinel.customConfig."min-replicas-to-write"	1	Мінімальна кількість реплік, доступних Redis-мастеру, для того, щоб він приймав операції зміни даних
sentinel.customConfig."min-replicas-max-lag"	10	Мінімальний час в секундах, який використовується як показник недоступності репліки при проведенні асинхронної реплікації або перевірок доступності

Налаштування

Значення

Опис

sentinel.replicas

Кількість екземплярів Sentinel-процесів

redis.replicas

Кількість екземплярів Redis-реплік

sentinel.quorum

Кількість Sentinel-процесів, яка необхідна для підтвердження непрацездатності / недоступності Redis-мастера

sentinel.customConfig."down-after-milliseconds"

60000

Час в мілісекундах, протягом якого екземпляр Redis має бути недоступним, щоб Sentinel почав вважати його непрацездатним

sentinel.customConfig."failover-timeout"

180000

Час в мілісекундах, який використовується у якості затримки при підтвердженні недоступності Redis-мастера

sentinel.customConfig."parallel-syncs"

Кількість Redis-реплік, які є одночасно недоступними у процесі реконфігурації на використання нового Redis-мастера у разі автоматичного відновлення

sentinel.customConfig."min-replicas-to-write"

Мінімальна кількість реплік, доступних Redis-мастеру, для того, щоб він приймав операції зміни даних

sentinel.customConfig."min-replicas-max-lag"

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

5.3. Конфігурація клієнтських сервісів

Приклад конфігурації підключення до Redis Sentinel для Сервісу обслуговування запитів на внесення змін даних реєстру

lowcode-form-data-storage:
  type: redis
  backend:
    redis:
      keyspace: 'bpm-form-submissions'
      username: ${redis-secret:redis.username} [redis data node auth]
      password: ${redis-secret:redis.password} [redis data node auth]
      sentinel:
        master: <sentinel-redis-master-group-name>
        nodes: <redis-sentinel-service>:<redis-sentinel:port>
        username: ${redis-secret:redis.sentinel.username} [sentinel auth]
        password: ${redis-secret:redis.sentinel.password} [sentinel auth]
lowcode-file-storage:
  type: ceph
  backend:
    ceph:
      http-endpoint: ${lowcode-file-ceph.http-endpoint}
      access-key: ${lowcode-file-ceph.access-key}
      secret-key: ${lowcode-file-ceph.secret-key}
      bucket: ${lowcode-file-ceph.bucketName}
datafactory-form-data-storage:
  type: ceph
  backend:
    ceph:
      http-endpoint: ${datafactoryceph.http-endpoint}
      access-key: ${datafactoryceph.access-key}
      secret-key: ${datafactoryceph.secret-key}
      bucket: ${datafactoryceph.bucketName}

Приклад конфігурації підключення до Redis Sentinel для Сервісу виконання бізнес-процесів

storage:
  form-data:
    type: redis
    keyspace: 'bpm-form-submissions'
  message-payload:
    type: redis
    keyspace: 'bpm-message-payloads'
  backend:
    redis:
      username: ${redis-secret:redis.username} [redis data node auth]
      password: ${redis-secret:redis.password} [redis data node auth]
      sentinel:
        master: <sentinel-redis-master-group-name>
        nodes: <redis-sentinel-service>:<redis-sentinel:port>
        username: ${redis-secret:redis.sentinel.username} [sentinel auth]
        password: ${redis-secret:redis.sentinel.password} [sentinel auth]

6. Шифрування проміжних даних ("data-at-rest" )

6.1. Шифрування файлів у Ceph-бакеті lowcode-file-storage

Для збереження даних у зашифрованому вигляді, рекомендовано розглянути підхід Ceph Server-Side Encryption з використанням HashiCorp Vault у якості сервісу управління ключами та шифрування даних.

Розділ потребує доповнення

6.2. Шифрування даних у Redis

Для збереження даних у зашифрованому вигляді, рекомендовано розглянути підхід реалізації спеціальних механізмів серіалізації/десеріалізації даних на базі org.springframework.data.redis.serializer.RedisSerializer з використанням HashiCorp Vault Encryption as a Service.

Розділ потребує доповнення

7. Бекапування та відновлення проміжних даних

Створення резервної копії та відновлення даних, які зберігаються у сховищах Ceph та Redis виконується згідно до загальної процедури з використанням захищеного сховища бекапів.

Детальніше можно ознайомитись у розділі Бекап та відновлення реєстру.

8. Міграція проміжних даних БП

Зміна типу сховища проміжних даних впливає на бізнес-процеси, які знаходяться в одному зі станів:

ACTIVE
SUSPENDED

Для забезпечення коректності функціонування системи після встановлення нової версії, необхідно мігрувати дані, описані у розділі Опис складових проміжних даних БП з lowcode-form-data-storage Ceph-бакету до Redis Hash-структури з урахуванням сегрегації за keyspaces bpm-form-submissions / bpm-message-payloads та алгоритму генерації ключів згідно розділу Генерація цлючів для проміжних даних.