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

1. Проблематика

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

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

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

  • Взаємозв’язки між директоріями

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

  • Залежності для JUEL-функцій бізнес-процесів

Цілісний запит на внесення змін — це запит на зміни, після застосування якого, всі компоненти регламенту реєстру зберігають валідні взаємозв’язки.

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

3. Перевірка взаємозв’язків між директоріями регламенту реєстру

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

Наприклад, при редагуванні форми, яка містить пошуковий запит, на вкладці Data компонента Select ви внесли та зберегли неправильну назву точки інтеграції, яка відсутня у дата-моделі:

  • Правильне значення: /officer/api/data-factory/factor-all

  • Помилкове значення: /api/data-factory/folders.

regulations integrity 1

4. Перевірка залежності для JUEL-функцій бізнес-процесів

При використанні Script Task розробник може використовувати JUEL-функції у скрипті (детальніше див. JUEL-функції у бізнес-процесах).

Наприклад, що у такому скрипті ви передали JUEL-функції та зберегли некоректне значення ідентифікатора задачі:

  • Правильне значення: submission('signRequestDataFormActivity')

  • Неправильне значення: submission('signRequestFolderFormActivity')

regulations integrity 2

5. Перевірка взаємозв’язків при використанні типових розширень бізнес-процесів

Розробник регламенту у сервісній задачі (Service Task) може використати типове розширення. Наприклад, Create entity in data factory (детальніше про створення сутностей див. Створення сутності у фабриці даних (Create entity in data factory)), де у полі Resource необхідно вказати ресурс (назву таблиці) для збереження даних.

Наприклад, ви вказали значення, яке відсутнє у базі даних:

regulations integrity 3

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

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

regulations integrity 4

Тобто, після внесення некоректних даних до JUEL-функції, типового розширення та пошукового запита, система перевіряє ці дані та відображає ідентифікатори задач зі вказаними помилками.

regulations integrity 5

Така сама валідація проходить і на пайплайні MASTER-Build-registry-regulations при застосуванні некоректних змін до мастер-версії регламенту.

regulations integrity 6

Для релізу 1.9.7, знайдені помилки не перешкоджають подальшому розгортанню регламенту при проходженні інших кроків пайплайну.