Розробка регламенту у майстер-версії для форм та процесів: спрощення моделювання та захист від перезапису
🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію. |
1. Загальний опис
В процесі розробки або виправлення незначних помилок які не потребують значних змін в регламенті розробнику все одно доводиться робити велику кількість дій, а саме: створення версії кандидати в Адмін порталі, внесення змін в регламент та інтеграція змін в мастер-версію. Це вимагає великої кількості часу та зусиль. Для покращення досвіду моделювання необхідно надати можливість вносити зміни в безпосередньо в мастер-версію регламенту.
2. Функціональні сценарії
-
Редагування форми безпосередньо в мастер-версії регламенту реєстру
-
Редагування бізнес-процесу безпосередньо в мастер-версії регламенту реєстру
-
Створення форми безпосередньо в мастер-версії регламенту реєстру
-
Створення бізнес-процесу безпосередньо в мастер-версії регламенту реєстру
-
Редагування форми в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату
-
Редагування бізнес-процесу в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату
-
Створення форми в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату
-
Створення бізнес-процесу в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату
-
Копіювання форми в мастер-версії регламенту реєстру
-
Копіювання бізнес-процесу в мастер-версії регламенту реєстру
-
Видалення форми в мастер-версії регламенту реєстру
-
Видалення бізнес-процесу в мастер-версії регламенту реєстру
Усі функціональні сценарії належать до Вебінтерфейсу моделювання регламенту. |
3. Ролі користувачів
-
Розробник регламенту
4. Загальні принципи та положення
-
Розробник регламенту може редагувати,створювати або видаляти форму або бізнес-процес безпосередньо в мастер-версії регламенту реєстру
-
Сутність - це загальна назва форми або бізнес-процесу в цьому документі
-
Спрощений процес створення версії кандидату містить в собі автоматизовану послідовність кроків при натисканні кнопки редагування/створення/видалення сутності, а саме внесення інформації про версію-кандидат, створення версії кандидату, внесення змін в сутність та збереження змін в версії кандидату
-
При редагуванні, створенні та видаленні сутності необхідно забезпечити захист від перезапису змін, які можуть бути внесені іншими моделювальниками
-
При створенні сутності повинна виконуватися перевірка на наявність сутності з таким іменем
-
При редагуванні та видаленні сутності повинна виконуватися перевірка на те що зміни застосовуються відносно останньої версії сутності (незалежно у версії-кандидаті чи мастер-версії)
-
При перевірці на зміни повинно враховуватися що зміни можуть бути внесені як через Адмін портал, так і напряму у Gerrit
-
При редагуванні та видаленні сутності (http method PUT, DELETE) використовується загальний RestAPI Optimistic locking підхід який використовується в системі
-
При наявності змін, що конфліктують система після обробки такого запиту повинна залишатися в консистентному стані
-
При наявності змін, що конфліктують користувач повинен власноруч скопіювати контент, який редагував, оновити сторінку з сутністю та внести зміни вручну
-
При заведенні змін безпосередньо в мастер повинен створюватися Gerrit MR з параметром submit та private. Submit - вказує на те, що зміни повинні бути відразу інтегровані. Private - використовується для розділення для маркування змін, які не потребуються запуски пайплайну перевірки регламенту (додаткове налаштування в Jenkins-Gerrit інтеграції)
5. Високорівневий дизайн рішення
5.1. Захист від перезапису
6. Обсяг робіт
6.1. Попередня декомпозиція
-
[FE] Додати можливість створення/редагування форми/бізнес-процесу з мастер-версії
-
[BE] Розширити API для роботи з формами та бізнес-процесами в мастер-версії
-
[DEVOPS] Налаштувати пайплайн перевірки регламенту на роботу тільки з публічними змінами Gerrit (exclude Private changes)
-
[FE] Додати спрощений процес створення версії кандидату зі сторінки створення сутності
-
[FE] Додати посилання на Jenkins для відстежування результату публікації регламенту в Адмін Порталі
-
[FE] Додати обробку помилок з конфліктами з підказками по діям користувачу
-
[BE] Реалізувати BusinessProcessEtagInterceptor для перевірки etag при оновленні бізнес-процесу
-
[BE] Додати перевірку на дублікат імен при створенні сутності на рівні VersionedFileRepository
-
[BE] Додати перевірку по etag при оновленні сутності на рівні VersionedFileRepository
-
[BE] Додати обробку merge conflicts при публікації змін в Gerrit
-
[BE] Розширити HeadFileRepositoryImpl підтримкою запису файлів в репозиторій
-
[BE] Розширити HeadFileRepositoryImpl підтримкою видалення файлів в репозиторій
-
[FE] Додати можливість копіювання сутності в мастер-версії
-
[FE] Додати можливість видалення сутності в мастер-версії
-
[DEVOPS] Додати права сервіс акаунту RRM на виконання update by submit операції в Gerrit
6.2. Зміни в REST API
Registry Regulation Management
6.3. Обмеження рішення
-
При змінах, що конфліктують користувачу потрібно власноруч скопіювати контент, оновити сторінку та повторити збереження з аналізом конфліктів
-
Поточний дизайн не покриває фактичне видалення форм та бізнес-процесів в Form-management-provider та BPMS відповідно