Автоматичне застосування видалення складових регламенту до реєстру

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

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

  • Розгортання регламенту реєстру

  • Моделювання регламенту за допомогою вебінтерфейсу

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

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

  • Адміністратор реєстру

Загальні положення

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

  • Дані породжені цими компонентами, такі як історія виконання бізнес-процесів, згенеровані витяги та ін., зберігаються в системі.

Технічне рішення

Шаблони витягів

При розгортанні регламенту, утилітою report-publisher додатково повинні виконуватися наступні дії:

  • При виклику з аргументом --excerpts:

    • Видаляти із БД excerpt ті шаблони для яких нема відповідних директорій в папці excerpt регламенту.

  • При виклику з аргументом --excerpts-docx або -- excerpts-csv:

    • Видаляти із БД excerpt ті шаблони для яких нема відповідних файлів в папці excerpts-docx чи excerpts-csv регламенту.

    • Видаляти із бакету excerpt-templates файли шаблонів яких не існує в папці excerpts-docx чи excerpts-csv регламенту

Інформація про видалення шаблонів повинна журналюватися, тобто потрапляти в лог, і бути доступною до перегляду в jenkins.

Записи генерації витягів та статусу (excerpt_record) видаляти не потрібно.
Перевірка відсутності залежностей бізнес процесів від видалених шаблонів повинна відбуватися при валідації регламенту перед розгортанням.

Форми

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

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

OpenAPI Specification (Завантажити)

Використовуючи цей новий API, отримати список форм що встановлені у сервісі та порівняти його із списком в регламенті. Ті форми яких нема в регламенті мають бути видалені за допомогою методу DELETE /api/forms/{key} сервісу постачання UI-форм.

Інформація про видалення форм повинна журналюватися, тобто потрапляти в лог, і бути доступною до перегляду в jenkins.

Згідно з принципом найменших привілеїв, політики авторизації для цього методу мають дозволяти його виклик тільки користувачам admin реалму, зокрема користувачу jenkins-deployer.

Інші методи API цього сервісу, які використовуються тільки підсистемою розгортання регламенту, можуть бути обмежені такою самою політикою. Користувачам citizen та officer реалмів доступним має залишитись тільки метод GET /api/forms/{key}, який використовує вебінтерфейсом кабінетів для отримання форм.
Перевірка відсутності залежностей бізнес процесів від видалених форм повинна відбуватися при валідації регламенту перед розгортанням.

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

При натисканні на кнопку видалити форму, додати попередження, яке інформує користувача що:

  • При розгортанні регламенту форма буде видалена з реєстру

  • Якщо є бізнес-процеси які використовують цю форму, вони перестануть працювати. Це стосується також незавершених екземплярів бізнес-процесу старих версій.

Бізнес-процеси та правила

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

Для видалення бізнес-процесів треба виконати наступні дії:

  • Просканувати всі файли .bpmn в регламенті та зібрати список ідентифікаторів process definitions <bpmn:process id="abc"> які в цих файлах присутні.

  • Порівняти цей список із списком process definitions отриманим із сервісу bpms (GET /process-definition)

  • Ті process definitions, які присутні в сервісі але відсутні у файлах регламенту, видалити із сервісу. Для видалення всіх версій необхідно повторювати команду DELETE /process-definition/key/{key} доки вона не поверне статус 404, що вказує на відсутність процесів із цим ключем.

Для видалення правил алгоритм такий:

  • Просканувати всі файли .dmn в регламенті та зібрати список ідентифікаторів правил <decision id="abc">, які в цих файлах присутні.

  • Порівняти цей список із списком правил отриманим із сервісу bpms (GET /decision-definition)

  • Ті правила, які присутні в сервісі але відсутні у файлах регламенту, видалити із сервісу. Оскільки camunda не надає метод для видалення правил, для цього необхідно виконати декілька кроків:

    1. Отримати deploymentId правила за допомогою GET /decision-definition/key/{key}

    2. Видалити знайдений деплоймент (DELETE /deployment/{id}), разом з яким буде видалено і відповідне правило.

    3. Для видалення всіх версій необхідно повторювати команди, доки GET /decision-definition/key/{key} не поверне статус 404, що вказує на відсутність правил із цим ключем.

Інформація про видалення бізнес-процесів та правил повинна журналюватися, тобто потрапляти в лог, і бути доступною до перегляду в jenkins.

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

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

В процедурі автоматичного видалення проміжних даних бізнес-процесів, має також оброблятись статус INTERNALLY_TERMINATED, з яким завершуються процеси при видаленні process definition.

Оновлення статусу бізнес-процесу та його задач в історії

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

В кабінеті користувача на вкладці "Виконані послуги" послуги, що були зупинені та видалені (статус INTERNALLY_TERMINATED) мають відображатися з результатом "Послуга видалена із системи та більше не доступна"

TIP

Фіксація статусу INTERNALLY_TERMINATED в БД вже працює в наявній реалізації, але історічні записи з таким статусом не відображаються в кабінеті. Для задач дата закінчення наразі не проставляється, отже вони і не відображуються у "виконаних задачах" в кабінеті.

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

При видаленні бізнес процесу, при натисканні на кнопку видалити бізнес-процес або при видаленні в конструкторі (коли в одному файлі декілька бізнес-процесів), додати попередження яке інформує користувача що:

  • При розгортанні регламенту, бізнес-процес буде видалений з реєстру

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

Міграція

Впровадження автоматичного видалення компонентів регламенту, які не видалялись раніше, несе певні ризики при постачанні цієї функціональності на промислові оточення. Наприклад:

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

  • Є шанс що реєстр в своїй роботі покладається на якісь компоненти які були видалені з регламенту, помилково чи ні, але залишаються встановленими.

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

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

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

Підсистема Компонент Опис змін

Підсистема розгортання регламенту реєстру

registry-regulations-publications-pipelines

Видалення моделей бізнес-процесів (BPMN), бізнес-правил (DMN) та моделей форм реєстру.

report-publisher

Видалення шаблонів витягів

registry-regulations-validator-cli

Валідація порушення залежностей

Підсистема виконання бізнес-процесів

form-schema-provider

API отримання списку встановлених форм.

process-history-service-api

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

bpms

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

digital-documents

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

Підсистема моделювання регламенту реєстру

admin-portal

Попередження при видаленні бізнес-процесу чи форми

Високорівневий план розробки

Технічні експертизи

  • DevOps

  • BE

  • FE

Попередній план розробки

  • Додавання логіки видалення шаблонів витягів у report-publisher

  • Додавання API отримання списку встановлених форм у form-schema-provider

  • Додавання логіки видалення форм у registry-regulations-publications-pipelines

  • Додавання логіки видалення моделей бізнес процесів та бізнес-правил в registry-regulations-publications-pipelines

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

  • Відображення видалених бізнес-процесів і їх задач, як завершених, в кабінетах користувачів

  • Додавання попередження при видаленні бізнес-процесу чи форми в вебінтерфейсі моделювання регламенту

  • Додавання валідація цілісності регламенту для тих елементів які ще не реалізовані