Вимоги та рекомендації розробнику щодо моделювання регламенту реєстру

Дотримуйтесь єдиного стилю для імен таблиць і критеріїв пошуку:

Наприклад, таблиця може називатися koatuu, а критерій пошуку — sc_koatuu_contains_name або koatuu_contains_name_sc. Це спрощує ідентифікацію таблиць і критеріїв у процесі роботи.

Зі збільшенням кількості changeSet зростає складність файлу, що ускладнює його управління та розуміння. Велика кількість changeSet збільшує час застосування змін у базі даних. Тому важливо регулярно перевіряти актуальність changeSet, особливо після cleanup-процедури.

Під час роботи над регламентом реєстру можливо послідовно створювати різну кількість changeSet для внесення, видалення або модифікації таблиць і їх полів. Це може знизити читабельність файлу. Тому якщо до cleanup-процесу були присутні послідовні changeSet на виправлення, видалення або внесення змін до моделі даних, то після cleanup рекомендується видалити ChangeSet, які модифікували таблиці, і залишити лише ті, які створюють актуальну модель даних.

Якщо потрібно внести зміни до таблиці, видаліть її (разом із залежними компонентами у зворотному порядку їх створення) та створіть нову таблицю з актуальними змінами.

Для видалення кількох таблиць або критеріїв пошуку використовуйте один changeSet:

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

Пам’ятайте про продуктивність критеріїв пошуку при роботі з великими обсягами даних. Оператори й функції, такі як ORDER BY, GROUP BY, JOIN, а також функції агрегації COUNT(), SUM(), AVG(), MIN(), MAX(), можуть вимагати значних ресурсів. Для оптимізації запитів використовуйте індекси та регулярно аналізуйте продуктивність створених запитів.

Ліміти в критеріях пошуку визначають максимальну кількість результатів, що повертаються. Без лімітів можливий витік даних і зниження продуктивності системи.

Щоб зменшити обсяг даних і знизити навантаження на сервер, використовуйте атрибут limit разом з атрибутом pagination.

Під час створення критеріїв пошуку переконайтеся, що для полів, які використовуються для зв’язку таблиць і формування умов вибірки представлення, у таблицях із великою кількістю записів створені індекси. Індекси покращують швидкість і продуктивність запитів.

Не створюйте індекси для таблиць із невеликою кількістю даних. СКБД Postgres виділяє ресурси для створення та підтримки індексів і щоразу при запиті пошуку до бази даних розраховує оптимальні варіанти, як проводити пошук: якщо таблиця зберігає невелику кількість даних, то СКБД Postgres не буде використовувати індекси для пошуку. У таких випадках індекси лише займають пам’ять і ресурси.

Детальніше про створення й використання індексів читайте у розділі Атрибут indexing та доступні значення.

Покинуті з різних причин бізнес-процеси (помилка у бізнес-процесі чи незавершений користувачем процес), накопичуються у системі та фактично стають системним "сміттям". Вони не мають перспективи завершення, тому наполегливо рекомендується до користувацької задачі завжди додавати подію Timer. Після правильного налаштування елемента з таймером, незавершений процес у кабінеті користувача буде автоматично закриватися після відпрацювання таймера.

Рекомендуємо за замовчуванням додавати до БП подію Таймер з налаштуванням закривати бізнес-процес через тиждень. В окремих випадках, розуміючи бізнес-вимоги замовника, можна збільшувати або зменшувати цей період. Особливо актуально для високонавантажених систем.

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

Також користувач повинен мати можливість на етапі підпису UI-форми повернутися до головного меню без збереження внесених на формі даних. Детальніше про це див. у розділі Моделювання скасування внесення даних і повернення до головного меню.

Для сповіщення користувачів про обробку їхньої заявки або зміну її статусу, необхідно відправляти inbox (in-app) повідомлення у кабінет користувача. Також рекомендується відправляти додаткові сповіщення коли час, встановлений таймером, закінчується, і бізнес-процес автоматично завершується. Більше про налаштування відправлення in-app повідомлень користувачам див. на сторінці Відправлення in-app-повідомлень у скриньку Кабінету отримувача послуг.

На етапі розгляду звернення посадовою особою необхідно додати додаткову гілку для можливості відмовити у наданні послуг (якщо така можливість передбачена на нормативному рівні). У такому випадку посадова особа має вказати причину відмови реєстрації. Результат разом зі вказаною причиною відмови має зберігатися у Фабриці даних. У разі відхилення посадовою особи реєстрації, рекомендується також сповіщати отримувача послуги щодо відхилення реєстрації й надавати йому можливість внести корективи до форми.

У кабінеті посадової особи усі виконані бізнес-процеси зберігаються на вкладці Мої послуги  Надані послуги. Через те, що посадова особа може реєструвати одні й ті ж послуги різним особам, рекомендується вносити додаткові ідентифікатори, які надають можливість відрізняти послуги для різних осіб за індивідуальними даними — ПІБ, ЄДРПОУ або РНОКПП тощо.

Для цього налаштуйте ідентифікатори для процесів, наприклад, відображення ПІБ отримувача послуг або його ЄДРПОУ/РНОКПП, або іншого ідентифікатора, який допоможе швидко знайти потрібну послугу в переліку. Для реалізації ідентифікації під час моделювання бізнес-процесу використовуйте функцію налаштування бізнес-ключів на різних етапах процесу. Детальніше про бізнес-ключі див. на сторінці Налаштування бізнес-ключів у бізнес-процесах.

Після налаштування бізнес-ключа, в кабінеті посадової особи для кожного налаштованого процесу буде доданий ідентифікатор послуги.

Для уникнення зловживань, помилок і шахрайства налаштовуйте ролі з мінімально необхідними правами, потрібними лише для виконання конкретних етапів бізнес-процесу. Деталі — у принципах управління доступом.

У кабінеті користувача може відображатися велика кількість послуг, в результаті чого виникають труднощі з пошуком необхідної послуги. Рекомендуємо групувати можливі послуги за категоріями — так користувач бачитиме папки, що логічно об’єднують доступні для користувача процеси. Налаштування категоризації послуг розробник може виконувати в Адміністративному порталі (Кабінеті адміністратора регламенту). Покрокова інструкція доступна на сторінці Категоризація доступних послуг у кабінетах користувачів.