Робота з цифровими документами у Кабінеті користувача
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. |
Поточний технічний дизайн сфокусований на загальних аспектах реалізації вимог щодо роботи із файлами через Кабінети користувача та на особливостях взаємодії між підсистемами "Lowcode" та "Дата Фабрика" в цьому контексті.
1. Функціональні можливості
Для забезпечення вимог по роботі з цифровими документами через кабінет користувача, платформа надає наступні можливості:
-
Завантаження цифрових документів користувачами через UI-форми задач бізнес-процесів
-
Вивантаження та перегляд цифрових документів користувачами через UI-форми задач бізнес-процесів
2. Загальні принципи реалізації
-
Файли цифрових документів, завантажені через UI-форми задач, підлягають збереженню в об’єктному сховищі Ceph до моменту закінчення бізнес-процесу
-
Для усіх файлів цифрових документів, завантажених через UI-форми задач, генерується SHA256-геш та зберігається у вигляді атрибуту Ceph-документа для подальшого використання при накладанні підпису
-
Файли цифрових документів, завантажені через UI-форми задач, та дані форми зберігаються у вигляді окремих Ceph-документів в різних бакетах (lowcode-file-storage та lowcode-form-data-storage)
-
Для забезпечення цілістності даних, отриманих від користувача та завантажених ним файлів цифрових документів через UI-форму, Ceph-документ даних форми містить унікальні ідентифікатори Ceph-документів файлів та згенеровані з них SHA256-геші
-
Файли цифрових документів не є об’єктом виконання операцій на рівні бізнес-процесів на відміну від їх ідентифікаторів
-
При накладанні підпису приватним ключем користувача на дані форми з завантаженими файлами цифрових документів, підпис генерується на документ даних UI-форми, який містить унікальні ідентифікатори Ceph-документів та SHA256-геші файлів
-
Обмін цифровими документами між підсистемами платформи "Low-code" та "Дата Фабрика" реалізується внаслідок обміну унікальних ідентифікаторів та їх Ceph-документів через окремий Ceph-бакет "lowcode-file-storage"
-
Усі документи, які завантажені в рамках бізнес-процесу, зберігаються у вигляді Ceph-об’єктів в "lowcode-file-storage" бакеті під ключами з ознакою групування за префіксом (process/{processInstanceId}/{id}) процесу
-
Бакет "low-code-file-storage" призначений для тимчасового зберігання цифрових документів у процесі виконання бізнес-процесів. Для перманентного зберігання використовується окремий бакет "Дата Фабрики" - "registry-file-storage"
3. Взаємодія компонентів системи
На даній діаграмі зображено задіяні для реалізації вимог сервіси платформи та взаємодію між ними. Додатково зображено важливі особливості, які необхідно прийняти до уваги в рамках реалізації.
3.1. Сервіс цифрових документів
За реалізацію вимог по роботи з ціфровими документами через кабінет, відповідає окремий компонент "Сервіс цифрових документів", який використовує Ceph у якості сховища файлів.
Детальніше з дизайном компоненти "Сервіс цифрових документів" можна ознайомитися за посиланням |
3.2. Обмін цифровими документами між підсистемами платформи
-
Файли цифрових документів є невід’ємною частиною сутності, в рамках створення якої вони були збережені
-
REST API підсистеми "Дата Фабрика" оперує лише UUID-ідентифікаторами та SHA256-гешами на рівні структур даних сутностей
-
При виконанні запиту на збереження сутності, яка містить UUID-ідентифікатори, Дата Фабрика очікує, що в бакеті "lowcode-file-storage" є наявні Ceph-документи з ключами, які відповідають конвенції іменування process/{processInstanceId}/{UUID} (значення processInstanceId передається у вигляді заголовка "X-Source-Business-Process-Instance-Id" разом з запитом), SHA256-геші яких співпадають з тими, які були передані разом с запитом
-
При виконанні запиту на отримання сутності, яка містить UUID-ідентифікатори, Дата Фабрика гарантує клієнту наявність у бакеті "lowcode-file-storage" Ceph-документів з ключами, які відповідають конвенції іменування process/{processInstanceId}/{UUID} (значення processInstanceId передається у вигляді заголовка "X-Source-Business-Process-Instance-Id" разом з запитом), SHA256-геші яких співпадають з тими, які передані як частина сутності
-
Доступ до файлів, завантажених як вкладення до сутності, на рівні підсистеми "Low-code" можливий лише через отримання даних цієї сутності та послідуюче отримання документа за UUID-ідентифікатором документа через компоненту "Сервіс цифрових документів"
3.3. Контракт взаємодії між підсистемами платформи
{
"<file_property_name>": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
}
{
"<file_property_name>": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
}
3.4. Загальна структура Ceph-об’єктів, які задіяні в обміні між "Lowcode" та "Дата Фабрикою"
Назва атрибуту | Атрибут JSON-документа | Атрибут Ceph об’єкта | Значення |
---|---|---|---|
Ключ Ceph-об’єкта |
key |
Унікальний ідентифікатор Ceph-документу для збереження файла в області доступу поточного бізнес-процесу. Автоматично формується на базі згенерованого id згідно конвенції process/<processInstanceId>/<id> |
|
Ідентифікатор цифрового документу |
id |
UserMetaData.id |
Унікальний ідентифікатор файла, зформований з використанням генератора псевдо-випадкових чисел (cad2e994-0e32-4a9f-9959-b420e20d4522) |
Назва файлу |
name |
UserMetaData.name |
<Назва файлу> |
Тип контента |
type |
Content-Type (UserMetaData.type) |
application/pdf, image/png, image/jpeg |
Розмір |
size |
Content-Length (UserMetaData.size) |
<Розмір файлу> |
Контент документа |
content |
input |
<Контент файла> |
Геш документа |
checksum |
(UserMetaData.checksum) |
Згенерований SHA256-геш файла |
4. Сценарії взаємодії користувача з системою
4.1. Завантаження цифрових документів
На даній діаграмі зображено сценарій внесення даних з файловими вкладеннями в рамках виконання задачі користувачем, обробка даних в рамках бізнес-процесу та використання їх для попереднього заповнення наступної задачі користувача.
{
"data": {
"<file_property_name>": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
}
}
{
"data": {
"<file_property_name>": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
},
"x-access-token": "<X-Access-Token>"
}
4.2. Вивантаження цифрових документів
На даній діаграмі зображено сценарій отримання сутності з файловими вкладеннями, яка була попередньо збережена у Дата Фабриці та послідуюча її підготовка для відображення на UI-формі задачі користувача.
{
"data": {
"<file_property_name>": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
}
}
4.3. Підпис даних UI-форм з цифровими документами
На даній діаграмі зображено сценарій підпису даних з файловими вкладеннями в рамках виконання задачі користувачем, обробка даних в рамках бізнес-процесу та їх збереження в Дата Фабрику.
{
"data": {
"<file_property_name>": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
},
"signature": "<e-Signature>"
}
{
"data": {
"passport_scans": [
{
"id": "{UUID}",
"checksum": "{SHA256-hash}"
}
]
},
"x-access-token": "<X-Access-Token>",
"signature": "<e-Signature>"
}
5. Моделювання UI-форм
5.1. Типова конфігурація поля типу "File" для налаштування адміністратором регламента
Розділ меню |
Назва налаштування |
Значення |
Опис |
Display |
Label |
<На розсуд адміністратора> |
Текстовий опис поля для користувача |
API |
Property Name |
<На розсуд адміністратора> |
Назва поля у JSON-документі структури даних |
File |
Storage |
URL |
Збереження контента завантаженого файла на сервері |
File |
Url |
/documents |
Адреса сервісу цифрових документів |
File |
Display as Image(s) |
false |
Відображення піктограм для зображень, замість табличного вигляду |
Data |
Multiple Values |
false |
Підтримка завантаження декількох файлів |
File |
File Pattern |
application/pdf,image/jpeg,image/png |
Паттерн файлів, дозволених для завантаження |
File |
File Maximum Size |
<На розсуд адміністратора> |
Максимальний розмір одного файлу |
5.2. JSON-схема опису структури UI-форми з полем типу "File"
{
"components": [
{
"label": "<file_property_label>",
"storage": "url",
"key": "<file_property_name>",
"type": "file",
"url": "/documents",
"input": true
}
]
}