Спрощений процес розробки регламенту через мастер-версію для форм і бізнес-процесів та захист від перезапису змін

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

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

Функціональні сценарії

  • Редагування форми безпосередньо в мастер-версії регламенту реєстру

  • Редагування бізнес-процесу безпосередньо в мастер-версії регламенту реєстру

  • Створення форми безпосередньо в мастер-версії регламенту реєстру

  • Створення бізнес-процесу безпосередньо в мастер-версії регламенту реєстру

  • Редагування форми в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату

  • Редагування бізнес-процесу в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату

  • Створення форми в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату

  • Створення бізнес-процесу в мастер-версії регламенту реєстру зі спрощеним процесом створення версії кандидату

  • Копіювання форми в мастер-версії регламенту реєстру

  • Копіювання бізнес-процесу в мастер-версії регламенту реєстру

  • Видалення форми в мастер-версії регламенту реєстру

  • Видалення бізнес-процесу в мастер-версії регламенту реєстру

Всі функціональні сценарії відносяться до Веб-інтерфейсу моделювання регламенту

Ролі користувачів

  • Розробник регламенту

Загальні принципи та положення

  • Розробник регламенту може редагувати,створювати або видаляти форму або бізнес-процес безпосередньо в мастер-версії регламенту реєстру

  • Сутність - це загальна назва форми або бізнес-процесу в цьому документі

  • Спрощений процес створення версії кандидату містить в собі автоматизовану послідовність кроків при натисканні кнопки редагування/створення/видалення сутності, а саме внесення інформації про версію-кандидат, створення версії кандидату, внесення змін в сутність та збереження змін в версії кандидату

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

  • При створенні сутності повинна виконуватися перевірка на наявність сутності з таким іменем

  • При редагуванні та видаленні сутності повинна виконуватися перевірка на те що зміни застосовуються відносно останньої версії сутності (незалежно у версії-кандидаті чи мастер-версії)

  • При перевірці на зміни повинно враховуватися що зміни можуть бути внесені як через Адмін портал, так і напряму у Gerrit

  • При редагуванні та видаленні сутності (http method PUT, DELETE) використовується загальний RestAPI Optimistic locking підхід який використовується в системі

  • При наявності змін, що конфліктують система після обробки такого запиту повинна залишатися в консистентному стані

  • При наявності змін, що конфліктують користувач повинен власноруч скопіювати контент, який редагував, оновити сторінку з сутністю та внести зміни вручну

  • При заведенні змін безпосередньо в мастер повинен створюватися Gerrit MR з параметром submit та private. Submit - вказує на те, що зміни повинні бути відразу інтегровані. Private - використовується для розділення для маркування змін, які не потребуються запуски пайплайну перевірки регламенту (додаткове налаштування в Jenkins-Gerrit інтеграції)

Високорівневий дизайн рішення

component
Figure 1. Компонентна діаграма
create entity
Figure 2. Діаграма діяльності. Створення сутності
update entity
Figure 3. Діаграма діяльності. Оновлення сутності
delete entity
Figure 4. Діаграма діяльності. Видалення сутності

Захист від перезапису

Створення форми/бізнес-процесу. Захист від перезапису змін
Figure 5. Створення форми/бізнес-процесу. Захист від перезапису змін
Оновлення форми/бізнес-процесу. Захист від перезапису змін
Figure 6. Оновлення форми/бізнес-процесу. Захист від перезапису змін
Видалення форми/бізнес-процесу. Захист від перезапису змін
Figure 7. Видалення форми/бізнес-процесу. Захист від перезапису змін

Обсяг робіт

Попередня декомпозиція

  • [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

Зміни в REST API

Registry Regulation Management

Обмеження рішення

  • При змінах, що конфліктують користувачу потрібно власноруч скопіювати контент, оновити сторінку та повторити збереження з аналізом конфліктів

  • Поточний дизайн не покриває фактичне видалення форм та бізнес-процесів в Form-management-provider та BPMS відповідно