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

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

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

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

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

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-консоль

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

Середовище розробки (IDE):

- VSCode

- IntelliJ IDEA

Середовище розробки надає зручний візуалізований інтерфейс для роботи з регламентом у локальному Gerrit-репозиторії.

Оберіть одне з двох на вибір.

Camunda Modeler, плагіни й типові розширення бізнес-процесів

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

Текстовий редактор:

- Notepad++

- Sublime Text

Зручний текстовий редактор дозволить вам зручно працювати із файлами вихідного коду різних розширень.

Оберіть одне з двох на вибір.

Postman

Інструмент для розробки та тестування API. Він надає зручне середовище для створення, надсилання, тестування та документування HTTP-запитів.

За допомогою Postman можна легко взаємодіяти з різними типами API, включаючи REST, SOAP, GraphQL та інші. Інтерфейс Postman є інтуїтивно зрозумілим і має багато корисних функцій, які допомагають розробникам простіше працювати з API, зокрема:

- Взаємодія з Keycloak API (для управління користувачами, перевірки та відлагодження автентифікації тощо).

- Взаємодія з API бізнес-процесів та Фабрики даних для емуляції виклику реєстру зовнішніми системами через REST або SOAP API.

- Взаємодія з Redash API для створення візуалізацій, дашбордів при роботі з аналітичною звітністю у реєстрі.

DBeaver

Інструмент, який надає зручний і потужний інтерфейс для управління різними типами баз даних. Він є безплатним та з відкритим вихідним кодом (Open Source) і доступний для використання на різних операційних системах, включаючи Windows, macOS і Linux.

DBeaver підтримує багато різних типів баз даних, включаючи відомі системи, зокрема MySQL, PostgreSQL, Oracle та багато інших.

OpenShift CLI

OpenShift CLI (Command-Line Interface) — це інструмент командного рядка, який надає доступ до управління та взаємодії з кластером OpenShift.

OpenShift CLI надає доступ до різних команд, які можна виконувати з командного рядка. Ці команди дозволяють керувати різними аспектами OpenShift.

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

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

У розділ Реєстри ви побачите вкладку Швидкі посилання. Тут представлені посилання до вебінтерфейсів різних сервісів з коротким описом їх призначення.

quick links 1

Детальніше про кожен сервіс, його призначення, а також шаблон посилання ви можете переглянути на сторінці Швидкі посилання до сервісів реєстру.

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 — подальше поглиблення практичних навичок зі створення бізнес-процесів, ознайомлення із вкладеними сутностями.

© 2023 Платформа Реєстрів.