Налаштування регламенту для надання доступу до даних через SOAP та REST API
Якщо ваш реєстр є власником даних, і ви хочете виставляти інтеграційні API-точки, отримувати запити та віддавати дані іншим реєстрам або системам, виконайте наступні налаштування регламенту:
Для REST-взаємодії необхідно також надати доступ до реєстру в адміністративній панелі Control Plane. Детальніше про це — див. на сторінці Налаштування доступу до реєстрів. |
1. Налаштування авторизації для доступу до бізнес-процесів реєстру
Адміністратор реєстру має виконати налаштування авторизації на рівні регламенту.
|
-
Налаштуйте доступ до бізнес-процесів у цільовому реєстрі, який надаватиме свій API для обміну даними.
Для цього перейдіть до файлу bp-auth/external-system.yml у регламенті та визначте конфігурацію:
Приклад 1. Конфігураційний файл для надання доступу до бізнес-процесів у цільовому реєстріauthorization: realm: 'external-system' process_definitions: - process_definition_id: 'my-process-id' process_name: 'Назва вашого бізнес-процесу' process_description: 'Опис вашого бізнес-процесу' roles: - 'trembita-invoker'
У цьому прикладі ми вказуємо, що доступ необхідно надати до бізнес-процесу
my-process-id
для роліtrembita-invoker
з Keycloak-реалму-external-system
. Параметриprocess_name
таprocess_description
є опціональними, і не впливають на процес авторизації.Клієнт trembita-invoker
з однойменною роллю створюється автоматично оператором Keycloak в реалмі-external-system
при розгортанні реєстру. Облікові дані цього клієнта необхідно використовувати для всіх зовнішніх систем, яким потрібен доступ до реєстру на Платформі. -
Налаштуйте файл bp-trembita/external-system.yml у регламенті:
-
Налаштуйте змінні старту бізнес-процесу. Для цього вкажіть, які параметри очікуватиме бізнес-процес у блоці
start_vars
.Без визначення start_vars
бізнес-процес не запрацює. -
Налаштуйте змінні повернення. Для цього вкажіть у блоці
return_vars
, які параметри повертатиме бізнес-процес.Приклад 2. Налаштування API-контракту для бізнес-процесуtrembita: process_definitions: - process_definition_id: 'my-process-id' start_vars: - eduname return_vars: - id - name
У цьому прикладі ми вказуємо, що для запуску бізнес-процесу
my-process-id
у цільовому реєстрі, необхідно передати стартові змінні. Без них ви не зможете ініціювати бізнес-процес. Тут ми передаємо параметрeduname
— умовне ім’я учня.Приклад, як прийняти змінні у цільовому процесі, див. у розділі нижче: Моделювання бізнес-процесу для виклику у цільовому реєстрі. -
Також налаштуйте змінні повернення. Тут ми налаштовуємо, що бізнес-процес повертатиме параметри
id
таname
. Вони будуть записані до змінної результату в Output Parameters цієї ж сервісної задачі з делегатом.
-
2. Налаштування моделі даних
Створіть модель даних реєстру. Додайте нові критерії пошуку, що надаватимуть доступ на читання даних БД через API-представлення реєстру.
Детальніше про налаштування моделі даних ви можете переглянути на сторінці Налаштування атрибутів доступу до API-представлень реєстру. |
3. Моделювання бізнес-процесу для виклику у цільовому реєстрі
Змоделюйте бізнес-процес, до якого звертатимуться інші реєстри для отримання даних. Це може бути будь-який процес, передбачений бізнес-логікою вашого реєстру.
Для того, щоб запустити бізнес-процес у вашому реєстрі, вам необхідно прийняти надіслані стартові змінні, які очікуються. Це можна зробити за допомогою скрипт-задачі, як показано на прикладі. ![]() Зображення 1. Приймання стартових змінних процесу у цільовому реєстрі
|
Приклад .bpmn-моделі процесу, а також користувацькі .json-форми до нього ви можете знайти у регламенті демо-реєстру consent-data за посиланням: https://admin-tools-consent-data.apps.envone.dev.registry.eua.gov.ua/gerrit. Процес буде доступний за назвою BPMN-create-school-auto-sign.bpmn. Назви форм ви можете знайти всередині відповідних користувацьких задач бізнес-процесу у полі |