Навчальний курс по роботі з регламентом реєстру

Розділ містить навчальні та контрольні матеріали для розвитку практичних навичок по роботі з регламентом реєстрів.

Цей курс містить перелік навчальних завдань, які адміністратор регламенту виконуватиме покроково, від простого до складного.

Також для закріплення практичного матеріалу розроблено контрольні завдання.

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

1.1. Що таке регламент реєстру?

Регламент реєстру — це набір сутностей, що зібрані в окремому git-каталозі за певною структурою. Кожна сутність — це папка, що містить набір файлів (шаблони, схеми, конфігураційні файли тощо), які виконують певні задачі для роботи за певними правилами у рамках бізнес-процесів.

Детальніше — дивіться на сторінці Структура регламенту реєстру

1.2. Як розгортається регламент?

Розгортання регламенту реєстру автоматизовано інструментами CI/CD. За розгортання регламенту відповідає Jenkins-пайплайн публікацій MASTER-Build-registry-regulations та пов’язані пайплайни.

Детальніше — дивіться на сторінці Модель розгортання регламенту та пайплайн публікацій

Збірка коду (Build) стосується лише тих файлів, які були в останньому коміті (commit).

Наприклад:

  • У першому коміті (git commit) ви внесли зміни до 2-х файлів (form.json для UI-форми та process.bpmn для процесу) та зберегли зміни до майстер-версії Gerrit-репозиторію (git push + git merge).

  • Пайплайн публікацій регламенту не пройшов із помилкою на кроці валідації.

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

  • Пайплайн публікацій проходить, але в такому випадку ваш бізнес-процес не розгорнеться й не відобразиться у Кабінеті користувачів (хоча в Gerrit-репозиторії й лежатиме).

Для розв’язання такої проблеми необхідно, щоб після невдалої збірки (проходження пайплайну) у новому коміті також були присутні усі ті файли, які ви намагалися розгорнути з попереднім комітом.

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

Щоб додати файл (в якому не було помилок) в репозиторій, можете внести незначні зміни (відступ у кінці, або пробіл) — це необхідно для того, щоб він потрапив до нового коміту.

2. Що необхідно для початку роботи?

2.1. Налаштування локального середовища

  • Встановіть Git та Git Bash-консоль.
    Консоль необхідна для роботи із git-репозиторіями (Gerrit, GitHub, GitLab тощо) за допомогою git-команд.

  • Встановіть середовище розробки: VSCode, або IntelliJ IDEA тощо.
    Середовище розробки надає зручний візуалізований інтерфейс для роботи з регламентом у Gerrit.

  • Встановіть настільний застосунок Camunda Modeler, плагіни й типові розширення до нього.
    Застосунок дозволяє моделювати бізнес-процеси у нотації BPMN 2.0, імпортувати та зберігати схеми процесів у форматі .bpmn, використовувати кастомні конектори для розширення бізнес-логіки тощо.

  • Встановіть текстовий редактор: Notepad++, або Sublime Text.
    Зручний текстовий редактор дозволить вам зручно працювати із файлами вихідного коду різних розширень.

2.2. Інструменти розробки: робоче середовище

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

  1. OpenShift (Kubernetes) — консоль керування Платформою. Призначення:

    • Перегляд технічних логів.

    • Управління подами (програмами, частинами мікросервісної архітектури реєстру).

    • Перегляд посилань, що доступні в рамках реєстру (список посилань до вебпорталів, Gerrit, Jenkins тощо).

    • Перегляд секретів (username:password) для доступу до різних систем.

  2. Kibana — сервіс перегляду технічних логів.

    Найбільш поширені випадки використання Kibana:

    • Пошук причин помилки за traceId.

    • Пошук причетних логів за id конкретного бізнес-процесу (за аналогію до traceId).

    Документація:

    registry-develop:bp-modeling/bp/kibana.adoc.

  3. Gerrit — система рецензування коду, сховище коду регламенту реєстру.

    Документація:

    Процес розгортання регламенту в Gerrit.

  4. Jenkins — сервіс для автоматизованої збірки коду та розгортання компонентів регламенту. Призначення:

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

    • Перегляд логів, пов’язаних зі збіркою та розгортанням.

    Документація:

  5. Camunda Cockpit — сервіс для адміністрування екземплярів бізнес-процесів.

    Призначення:

    • Адміністрування бізнес-процесів

    • Моніторинг бізнес-процесів

    • Перевірка розгортання бізнес-процесів

    Посилання до сервісу:

    https://business-proc-admin-<registry-name>.apps.envone.dev.registry.eua.gov.ua/

    Документація:

    Адміністрування бізнес-процесів у Camunda Cockpit.

  6. Keycloak — сервіс управління ідентифікацією користувачів та надання їм прав доступу.

    Документація:

  7. Swagger — інструмент для перегляду згенерованих API-точок доступу реєстру.

    Посилання до сервісу:

    https://registry-rest-api-<registry-name>.apps.envone.dev.registry.eua.gov.ua/openapi.

    Обов’язково додавайте /openapi в кінець посилання, інакше ви потрапите до тестового середовища (пісочниці) Swagger.

  8. pgAdmin — інструмент для роботи із базою даних реєстру, перегляд таблиць та представлень (Search Conditions).

    Посилання до сервісу:

    https://pgadmin-<registry-name>.apps.envone.dev.registry.eua.gov.ua/.

  9. Redash — інструмент для роботи з аналітичною звітністю. Створення та перегляд аналітичної звітності, створення запитів (Queries) та дашбордів (Dashboards), публікація та експорт звітності.

    Є 2 екземпляри (сервіси) Redash:

    • redash-admin — необхідний для моделювання запитів та звітів зі сторони розробників/адміністраторів реєстру.

    Посилання до сервісу:

    https://redash-admin-<registry-name>.apps.envone.dev.registry.eua.gov.ua/

    Документація:

    • redash-viewer — необхідний для перегляду сформованих звітів зі сторони користувачів кабінету посадової особи (авторизація за допомогою КЕП ключа).

      Посилання до сервісу: https://redash-viewer-<registry-name>.apps.envone.dev.registry.eua.gov.ua/

3. Дорожня карта моделювання регламенту

Дорожня карта з моделювання регламенту (Roadmap) показує верхньорівневі етапи по роботі з основними сутностями регламенту та надає загальний контекст командам розробки та супроводу реєстрів.

На діаграмі представлено лише основні елементи регламенту.

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

registry regulations roadmap

4. Навчальні завдання

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

4.1. Створити модель даних реєстру

В рамках цього завдання моделювальники мають:

  1. Створити логічну модель даних, створити ERD-діаграму.

  2. Створити фізичну модель даних відповідно до логічної моделі:

    • Створити план розробки фізичної моделі:

      • Визначити первинні ключі для кожної із сутностей.

      • Визначити вторинні ключі, якщо вони є в сутності.

      • Визначити обов’язкові поля.

      • Визначити поля або комбінацію полів, що мають унікальні значення.

      • Визначити назву таблиць та полів латиницею.

    • Створити таблиці та зв’язки між ними.

    • Створити критерії пошуку (таблиці-представлення, VIEW).

    • Виконати первинне наповнення даними таблиць-довідників.

  3. Застосувати розроблену модель у регламенті.

Детальніше — дивіться на сторінці Завдання 1. Моделювання структур бази даних реєстру.

4.2. Змоделювати простий бізнес-процес без інтеграцій

В рамках цього завдання моделювальники мають:

  1. Змоделювати простий бізнес-процес без інтеграцій із фабрикою даних або іншими реєстрами.

  2. Створити UI-форми введення даних до бізнес-процесу.

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

  4. Застосувати зміни у регламенті.

Детальніше — дивіться на сторінці Завдання 2. Моделювання бізнес-процесу без інтеграцій.

4.3. Змоделювати бізнес-процес з інтеграцією

В рамках цього завдання моделювальники мають:

  1. Змоделювати бізнес-процес, що має інтеграцію з фабрикою даних.

    • Змоделювати гілки у бізнес-процесі.

    • Змоделювати уніфіковані кроки у бізнес-процесах за допомогою Call Activity.

  2. Змоделювати UI-форми введення даних до бізнес-процесу та налаштувати компоненти Select для отримання даних із фабрики даних.

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

  4. Застосувати зміни у регламенті.

Детальніше — дивіться на сторінці Завдання 3. Моделювання бізнес-процесу з інтеграцією.

4.4. Змоделювати бізнес-процес зі стартовою формою та залежними компонентами на формах

В рамках цього завдання моделювальники мають:

  1. Змоделювати бізнес-процес, який має стартову форму.

  2. Змоделювати UI-форми введення даних із залежними компонентами та компонентом Edit Grid.

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

  4. Застосувати зміни у регламенті.

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

4.5. Змоделювати бізнес-процес із декількома учасниками

В рамках цього завдання моделювальники мають:

  1. Змоделювати бізнес-процес, що має декількох учасників.

  2. Змоделювати UI-форми введення даних та налаштувати їх за допомогою formVariables.

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

  4. Застосувати зміни у регламенті.

Детальніше — дивіться на сторінці Завдання 5. Моделювання бізнес-процесу із декількома учасниками.

4.6. Розробити аналітичну звітність

В рамках цього завдання моделювальники мають:

  1. Змоделювати аналітичне представлення.

  2. Надати доступ до аналітичного представлення.

  3. Створити 3 запити (Query) в Redash.

  4. Створити дашборд в Redash.

  5. Вивантажити архів із дашбордом та розпакувати його в регламенті.

  6. Перенести зміни до віддаленого Gerrit-репозиторію.

  7. Перевірити сформований звіт у Кабінеті посадової особи.

Детальніше — дивіться на сторінці Завдання 6. Розробка аналітичних звітів.

4.7. Змоделювати бізнес-процес із викликом ШБО "Трембіта"

В рамках цього завдання моделювальники мають:

  1. Змоделювати 1 бізнес-процес.

  2. Змоделювати 3 форми внесення даних до бізнес-процесу.

  3. Надати доступи до бізнес-процесу для відповідних ролей.

  4. Зберегти створені артефакти до локального git-репозиторію.

  5. Перенести локальні зміни до віддаленого Gerrit-репозиторію.

  6. Перевірити працездатність бізнес-процесу.

Детальніше — дивіться на сторінці Завдання 7. Моделювання бізнес-процесу із викликом ШБО "Трембіта".

5. Контрольні завдання

Розділ охоплює контрольні завдання для самоперевірки після завершення навчальної частини. Наразі розроблені такі завдання, від простого до складного:

  • Контрольне завдання 1 — має на меті отримати поглиблені практичні знання зі створення бізнес-процесів на Платформі.

  • Контрольне завдання 2 — подальше поглиблення практичних навичок зі створення бізнес-процесів.

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