Каталог типових розширень до бізнес-процесів

ЗМІСТ

1. Встановлення каталогу типових розширень до бізнес-процесів

Для спрощення моделювання бізнес-процесів розроблені типові розширення-конектори — Element Templates.

1.1. Передумови

1.1.1. Встановлення застосунку Сamunda Modeler

  1. Завантажте архів із застосунком Camunda Modeler за посиланням.

    Рекомендовано використовувати версію саме 4.8.0 для стабільної роботи системи.

  2. Оберіть продукт Open Source Modeler та завантажте відповідну версію, сумісну із вашою операційною системою (наприклад, Windows 64bit);

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

    Папка із застосунком може мати, наприклад, таку назву:

    camunda-modeler-4.8.1-win-x64

1.1.2. Встановлення плагіну BPMN Linter

Встановіть плагін BPMN Linter для розширення функціональності Camunda та валідації ваших BPMN-діаграм.

  1. Перейдіть до офіційного репозиторію за посиланням.

  2. Натисніть кнопку Code → Download ZIP та завантажте архів.

    element temp install bpmnlint

  3. Після завантаження, розпакуйте вміст архіву до папки camunda-modeler-4.8.1-win-x64\resources\plugins застосунку Camunda.

  4. Перезапустіть додадок Camunda Modeler.

  5. Увімкніть плагін. Для цього натисність Plugins → BPMN Linter → Toggle Linting.

    Альтернативно застосуйте комбінацію клавіш Ctrl+L.

    element temp turn on bpmnlint

    Плагін вмикається та вимикається однаково — Ctrl+L.

1.2. Встановлення каталогу типових розширень для Windows OS

Виконайте настанови, подані нижче, для інсталювання каталогу Element Templates.

  1. Завантажте каталог типових розширень одним зі способів:

    • Спосіб 1.
      Отримайте каталог з Github-репозиторію за посиланням.

    • Спосіб 2.
      Отримайте каталог із захищеного сховища артефактів Nexus за посиланням: https://nexus-{CP-NAMESPACE}.{DNS-WILDCARD}/:

      {CP-NAMESPACE} _та {DNS-WILDCARD} є змінними, де {CP-NAMESPACE} — назва namespace (простору імен) у Nexus, а {DNS-WILDCARD} — значення DNS wildcard[2].

      Наприклад:

      https://nexus.apps.envone.dev.registry.eua.gov.ua/nexus

      • знайдіть папку business-process-modeler-extensions;

      • буде показано каталог папок типу version.build (наприклад, 0.0.1-SNAPSHOT.12);

      • оберіть папку з останньою версією;

      • оберіть .zip-файл у папці, що була відкрита (останньою версією zip може бути, наприклад, файл business-process-modeler-extensions-1.7.0.zip);

      • на вкладці Summary натисніть правою кнопкою миші на посилання Path. Таким чином розпочнеться завантаження .zip-архіву;

  2. Розпакуйте із заміною завантажений .zip-файл у підпапці resources вашої локальної директорії, де зберігається додаток. Приклад шляху може бути наступним: C:\Users\Downloads\camunda-modeler-4.8.1-win-x64\resources.

    • camunda-modeler-4.8.1-win-x64 — локальна директорія, в якій зберігається додаток.

    • resources — папка, що містить розширення (element-templates) та плагіни (plugins)_.

  3. Підсумкова структура директорії resources має виглядати наступним чином:

    bp element temp 02

  4. Підсумкова структура директорії element-templates має виглядати наступним чином:

    bp element temp 03

  5. Підсумкова структура директорії plugins має виглядати наступним чином:

    bp element temp 04

  6. Перезапустіть додаток Camunda Modeler.

  7. Перевірте доступність розширень у каталозі при моделюванні бізнес-процесу:

    • Створіть задачу — оберіть Create Task.

    • Натисніть іконку ключа — оберіть Change Type.

    • Вкажіть тип задачі — сервісна (Service Task), користувацька (User Task) або Call Activity.

    • Натисніть кнопку Open Catalog.
      В результаті відкриється каталог розширень Element Templates, які можна застосувати в процесі моделювання.

      bp element temp 01

1.3. Встановлення каталогу типових розширень для Mac OS

Виконайте настанови, подані нижче, для інсталювання каталогу Element Templates.

  1. Завантажте каталог розширень до бізнес-процесів за аналогією до пункту Встановлення каталогу типових розширень для Windows OS.

  2. Відкрийте термінал.

  3. Перейдіть до локальної директорії розміщення ресурсів Camunda Modeler за допомогою команди:

    cd ~/Library/Application\ Support/camunda-modeler/resources

  4. Створіть нову директорію під розширення категорії element templates у випадку, якщо її там немає, за допомогою команди:

    mkdir element-templates

  5. Скопіюйте всі JSON-файли розширень із директорії business-process-modeler-extensions до директорії, що була створена, за допомогою команди:

    cp business-process-modeler-extensions/*.json ~/Library/Application\ Support/camunda-modeler/resources/element-templates

  6. Підсумкова структура директорії виглядатиме наступним чином:

    ~/Library/Application\ Support/camunda-modeler/resources/element-templates/

    bp element temp 05

  7. Перезапустіть додаток Camunda Modeler.

  8. Перевірте доступність розширень у каталозі при моделюванні бізнес-процесу:

    • Створіть задачу — оберіть Create Task.

    • Натисніть іконку ключа — оберіть Change Type.

    • Вкажіть тип задачі — сервісна (Service Task), користувацька (User Task) або Call Activity.

    • Натисніть кнопку Open Catalog.
      В результаті відкриється каталог розширень Element Templates, які можна застосувати в процесі моделювання.

      bp element temp 01

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

Цей розділ описує налаштування типових розширень для бізнес-процесів — Element Templates.

Типи задач для застосування розширень

Типові розширення Element Templates можуть бути застосовані до різних типів задач, наприклад:

Налаштування типових розширень-конекторів відбувається у застосунку Camunda Modeler.

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

2.1. Типові розширення для користувацьких задач

2.1.1. Задача, що потребує валідації підписом особи-отримувача послуг реєстру (Citizen Sign Task)

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

Перш за все, переконайтеся, що папка /element-templates містить файл citizenSignTaskTemplate.json.

  • Відкрийте User Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Form key введіть службову назву форми.

  • У полі Assignee введіть значення ${initiator}, (для того, щоб призначити задачу одразу користувачеві, що ініціював бізнес-процес) або значення ідентифікатора користувача (для того, щоб призначити задачу одному чітко визначеному користувачу).

  • У полі Candidate users введіть список користувачів (написаних через кому), для котрих задача буде доступною для виконання. В рамках бізнес-процесу кожен користувач зможе цю задачу призначити собі та виконати.

  • У полі Candidate roles введіть список ролей (написаних через кому), для яких задача доступна для виконання. В рамках бізнес-процесу кожен користувач, що має хоча б одну з цих ролей зможе цю задачу призначити собі та виконати (навіть якщо у нього немає доступу до самого бізнес-процесу.

Наприклад, бізнес-процес із умовною назвою bp1 зможе ініціювати лише користувач з роллю officer-bp1, хоча задачу в цьому бізнес-процесі, яка доступна ролі officer-task зможе виконати користувач, лише маючи одну регламенту роль officer-task).

  • Проставте необхідні прапорці у наступних полях, вказавши валідаційний пакет підпису:

    • CITIZEN — для регламентної ролі Фізична особа;

    • ENTERPRENEUR — для регламентної ролі Фізична особа-підприємець (ФОП);

    • LEGAL — для регламентної ролі Юридична особа.

bp element temp 1

2.1.2. Задача, що потребує валідації підписом посадової особи (Officer Sign Task)

Розширення використовується для визначення задачі, що потребує валідації підписом посадової особи.

Перш за все, переконайтеся, що папка /element-templates містить файл officerSignTaskTemplate.json.

  • Відкрийте User Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Form key введіть службову назву форми.

  • У полі Assignee введіть значення ${initiator}, (для того, щоб призначити задачу одразу користувачеві, що ініціював бізнес-процес) або значення ідентифікатора користувача (для того, щоб призначити задачу одному чітко визначеному користувачу).

  • У полі Candidate users введіть список користувачів (написаних через кому), для котрих задача буде доступною для виконання. В рамках бізнес-процесу кожен користувач зможе цю задачу призначити собі та виконати.

  • У полі Candidate roles введіть список ролей (написаних через кому), для яких задача доступна для виконання. В рамках бізнес-процесу кожен користувач, що має хоча б одну з цих ролей зможе цю задачу призначити собі та виконати (навіть якщо у нього немає доступу до самого бізнес-процесу.

Наприклад, бізнес-процес із умовною назвою bp1 зможе ініціювати лише користувач з роллю officer-bp1, хоча задачу в цьому бізнес-процесі, яка доступна ролі officer-task зможе виконати користувач, лише маючи одну регламенту роль officer-task).

bp element temp 2

2.1.3. Користувацька форма (User form)

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

Перш за все, переконайтеся, що папка /element-templates містить файл userTaskTemplate.json.

  • Відкрийте User Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Form key введіть службову назву форми.

  • У полі Assignee введіть значення ${initiator}, (для того, щоб призначити задачу одразу користувачеві, що ініціював бізнес-процес) або значення ідентифікатора користувача (для того, щоб призначити задачу одному чітко визначеному користувачу).

  • У полі Candidate users введіть список користувачів (написаних через кому), для котрих задача буде доступною для виконання. В рамках бізнес-процесу кожен користувач зможе цю задачу призначити собі та виконати.

  • У полі Candidate roles введіть список ролей (написаних через кому), для яких задача доступна для виконання. В рамках бізнес-процесу кожен користувач, що має хоча б одну з цих ролей зможе цю задачу призначити собі та виконати (навіть якщо у нього немає доступу до самого бізнес-процесу.

Наприклад, бізнес-процес із умовною назвою bp1 зможе ініціювати лише користувач з роллю officer-bp1, хоча задачу в цьому бізнес-процесі, яка доступна ролі officer-task зможе виконати користувач, лише маючи одну регламенту роль officer-task).

bp element temp 3

2.2. Типові розширення для сервісних задач

2.2.1. Додавання ролі користувачу Keycloak (Add role to Keycloak user)

Розширення використовується для призначення ролі користувача Keycloak.

Перш за все, переконайтеся, що папка /element-templates містить файл addRoleToKeycloakUser.json.

  • Відкрийте Service Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі User name вкажіть ідентифікатор користувача у Keycloak.

  • У полі Role вкажіть роль користувача.

bp element temp 4

2.2.2. Збереження ролей користувачів до Keycloak (Save user roles)

Таблиця 1. Короткі відомості про делегат
Назва Пояснення

Бізнес-назва інтеграційного розширення

Save user roles

Службова назва інтеграційного розширення

${keycloakSaveUserRoleConnectorDelegate}

Назва файлу у бібліотеці розширень

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

Загальне інтеграційне розширення-делегат надає можливість взаємодіяти із сервіс управління ідентифікацією та доступом Keycloak для зміни ролей користувача. Делегат налаштовується у сервісних задачах (Service Task) бізнес-процесу за допомогою шаблону Save user roles.

Налаштування

  1. Створіть Service Task.

  2. У полі Name вкажіть назву сервісної задачі.

  3. Застосуйте шаблон делегата Save user roles зі списку доступних у каталозі.

  4. У секції Inputs > Roles передайте ролі, які необхідно призначити користувачу. Наприклад, officer.

    У нашому прикладі передається одна роль (officer) масивом (List).

    Доступні типи змінних, через які можна передати ролі:

    • List — список/масив;

    • Map — ключі-значення;

    • Script — скрипт;

    • String or expression — рядок або вираз.
    Приклад 1. Масив ролей, які необхідно призначити користувачу
    ['officer', 'manager1', 'manager2']

    • officer — системна роль, яка призначається користувачу після реєстрації.

    • manager1 та manager2 — можуть бути регламентними ролями у реєстрі.

  5. Вкажіть ім’я користувача (username) у системі Keycloak. Це можна зробити, наприклад, за допомогою juel-функції initiator():

    ${initiator().userName}

  6. Оберіть реалм Keycloak, до якого відноситься користувач. Наприклад, officer, при реєстрації посадових осіб.

    Доступні опції реалмів:

    • CITIZEN — реалм, в якому зберігаються отримувачі послуг та їх ролі.

    • OFFICER — реалм, в якому зберігаються посадові особи (надавачі послуг) та їх ролі.

  7. Вкажіть тип ролей, які можуть бути змінені для користувача. Доступні опції:

    • ALL ROLES — усі поточні ролі будуть заміщені переліком ролей, вказаних у секції Roles.

    • PLATFORM ROLES — поточні системні ролі, призначені користувачу, будуть заміщені переліком ролей, вказаних у секції Roles. Поточні регламентні/реєстрові ролі залишаться без змін.

    • REGISTRY ROLES — у користувача будуть заміщені лише регламентні/реєстрові ролі.

  • Якщо при налаштуванні делегата як input-параметри передати масив ролей, одна з яких — системна, а дві інші - регламентні (тут — officer та manager1 і manager2), то необхідно обрати опцію ALL ROLES.

  • Якщо при налаштуванні делегата передати системну роль (тут — officer), то необхідно обрати опцію PLATFORM ROLES.

  • Якщо при налаштуванні делегата передати регламентні ролі (тут — manager1 і manager2), то необхідно обрати опцію REGISTRY ROLES.

delegate save user roles 1

2.2.3. Створення сутностей масивом у фабриці даних (Batch creation of entities in data factory)

Новіша версія цього інтеграційного розширення описана нижче, у розділі Створення сутностей масивом у фабриці даних (Batch creation of entities in data factory v2).
Таблиця 2. Короткі відомості про делегат
Назва Пояснення

Бізнес-назва інтеграційного розширення

Batch creation of entities in data factory

Службова назва інтеграційного розширення

${dataFactoryConnectorBatchCreateDelegate}

Назва файлу у бібліотеці розширень

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

Загальне інтеграційне розширення-делегат надає можливість взаємодіяти з REST API реєстру та створювати сутності у базі даних масивом. Делегат налаштовується у сервісних задачах (Service Task) бізнес-процесу за допомогою шаблону Batch creation of entities in data factory.

Налаштування шаблону у бізнес-процесі:
При налаштуванні делегата у додатку Camunda Modeler, переконайтеся, що папка із застосунком resources > element-templates містить файл dataFactoryConnectorBatchCreateDelegate.json.

  1. Відкрийте Service Task, натисніть Open Catalog та оберіть шаблон зі списку, після чого натисніть Apply.

    bp element temp 5

  2. У полі Name вкажіть назву задачі.

  3. У полі Resource вкажіть ресурс, назву ендпоінту для таблиці, куди зберігатимуться дані. Наприклад, diplomas.

  4. У полі Payload введіть дані для створення, що передаються як тіло запита. Наприклад, ${payload}.
    Payload зазвичай формується у попередній скрипт-задачі процесу та передається до сервісної задачі як змінна.

  5. У полі X-Access-Token source вкажіть токен доступу користувача до системи, під яким виконується операція. Наприклад, ${completer('signCsvFileActivity').accessToken}.

  6. У полі X-Digital-Signature source вкажіть джерело цифрового підпису. Наприклад, ${sign_submission('signCsvFileActivity').signatureDocumentId}.

  7. У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

    bp element temp 5 1

2.2.4. Створення сутностей масивом у фабриці даних (Batch creation of entities in data factory v2)

Таблиця 3. Короткі відомості про делегат
Назва Пояснення

Бізнес-назва інтеграційного розширення

Batch creation of entities in data factory v2

Службова назва інтеграційного розширення

${dataFactoryConnectorBatchCreateDelegateV2}

Назва файлу у бібліотеці розширень

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

Загальне інтеграційне розширення-делегат надає можливість взаємодіяти з REST API реєстру та створювати сутності у базі даних масивом як LIST або CSV транзакційно — тобто зберігаються або усі дані, або жодні. Делегат налаштовується у сервісних задачах (Service Task) бізнес-процесу за допомогою шаблону Batch creation of entities in data factory v2.

Максимальна кількість записів для завантаження до БД через цей делегат — 50:

  • 50 записів для LIST

  • 50 записів для CSV.
Детальніше про застосування делегата у бізнес-процесах ви можете переглянути на сторінці Моделювання бізнес-процесу для завантаження даних з CSV-файлу масивом у БД.
Налаштування шаблону у бізнес-процесі:
При налаштуванні делегата у додатку Camunda Modeler, переконайтеся, що папка із застосунком resources > element-templates містить файл dataFactoryConnectorBatchCreateDelegateV2.json.

  1. Відкрийте Service Task, натисніть Open Catalog та оберіть шаблон зі списку, після чого натисніть Apply.

    loading data from csv 05

  2. У полі Name вкажіть назву задачі.

  3. У полі Resource вкажіть ресурс, назву ендпоінту для таблиці, куди зберігатимуться дані. Наприклад, diplomas.

  4. У полі Upload type оберіть формат завантаження даних зі списку — CSV, або LIST.

    Для обох типів, CSV та LIST, конфігурація конектора є однаковою. Відрізнятиметься лише ${payload}, який зазвичай формується у попередній скрипт-задачі процесу та передається до сервісної задачі як змінна ${payload}.

    • Якщо необхідно завантажити дані масивом у CSV-форматі, то payload може формуватися у скрипті наступним чином:

      Приклад формування payload (CSV)
      set_transient_variable('payload', submission('signCsvFileActivity').formData.prop('csvFile').elements().first())

      Тобто отримуємо список елементів csvFile із форми (formData) за допомогою JUEL-функції submission(), формуємо об’єкт payload й надалі використовуємо як змінну при налаштуванні делегата. СSV-дані на форму можна завантажити за допомогою компонента Content (детальніше про моделювання форм — за посиланням).

    • Якщо необхідно завантажити дані масивом як LIST, то payload може формуватися у скрипті наступним чином:

      Приклад формування масиву даних (LIST)
      var data=
'''
[
   {
      "data":"test data",
      "description":"some description"
   },
   {
      "data2":"test data2",
      "description2":"some description2"
   }
]
'''

execution.setVariable("jsonArray", S(data))

      Створюємо рядок data, який містить JSON-масив із двома об’єктами. Кожен об’єкт містить пари ключ-значення — дані, які беруться з UI-форми. Результат записуємо до змінної jsonArray, яку потім використовуємо при налаштуванні делегата. дані на форму можна завантажити як масив за допомогою компонента Edit Grid (детальніше про моделювання форм — за посиланням).

  5. У полі Payload введіть дані для створення, що передаються як тіло запита. Наприклад, ${payload}.

  6. У полі X-Access-Token source вкажіть токен доступу користувача до системи, під яким виконується операція. Наприклад, ${completer('signCsvFileActivity').accessToken}.

  7. У полі X-Digital-Signature source вкажіть джерело цифрового підпису. Наприклад, ${sign_submission('signCsvFileActivity').signatureDocumentId}.

  8. У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

    loading data from csv 04

2.2.5. Групове читання сутностей у фабриці даних (Batch Read entities from data factory)

Перш за все, переконайтеся, що папка /element-templates містить файл dataFactoryConnectorBatchReadDelegate.json.

  • Відкрийте Service Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Resource вкажіть ресурс.

  • У полі Resource ids вкажіть ідентифікатор ресурсу.

  • У полі X-Access-Token source зазначте токен доступу до системи користувача, під яким виконується операція.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 6

2.2.6. Створення сутності у фабриці даних (Create entity in data factory)

Перш за все, переконайтеся, що папка /element-templates містить файл dataFactoryConnectorCreateDelegate.json.

  • Відкрийте Service Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Resource вкажіть ресурс.

  • У полі Payload введіть дані для створення.

  • У полі X-Access-Token source зазначте токен доступу до системи користувача, під яким виконується операція.

  • У полі X-Digital-Signature source вкажіть джерело цифрового підпису.

  • У полі X-Digital-Signature-Derived source вкажіть джерело системного цифрового підпису.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 7

2.2.7. Створення декількох сутностей в рамках однієї транзакції (Create nested entities in data factory)

Розширення Create nested entities in data factory — делегат для створення декількох сутностей в рамках однієї транзакції, що налаштовується за допомогою розробленого однойменного шаблону Create nested entities in data factory (dataFactoryConnectorNestedCreateDelegate.json).

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка /element-templates містить файл dataFactoryConnectorNestedCreateDelegate.json.

  1. Змоделюйте сервісну задачу (Service Task).

    nested entities 1

  2. Натисніть Open Catalog та оберіть шаблон Create nested entities in data factory зі списку.

    nested entities 2 nested entities 3

  3. Сконфігуруйте обраний шаблон:

    • У полі Name вкажіть назву задачі. Наприклад, Зберегти дані до Фабрики даних.

    • У полі Resource вкажіть ресурс, тобто назву ендпоінту, до якого необхідно звернутися. Наприклад, person-profile.

      На рівні API, ендпоінт виглядає наступним чином: /nested/<resource name>, де <resource name> — назва ресурсу. Тобто у полі Resource необхідно вказати значення, яке визначається після останньої косої риски (/).

    • У полі Payload введіть тіло запита — JSON-об`єкт із вкладеною структурою декількох сутностей, яку необхідно зберегти до Фабрики даних. Наприклад, ${payload}.

      Майте на увазі, що необхідно попередньо побудувати цей JSON-об`єкт, тобто payload, в рамках задачі скриптування.

    • У полі X-Access-Token вкажіть токен доступу.

      Токен доступу береться з АБО ініціатора (наприклад, $initiator().accessToken}), АБО виконавця задачі (наприклад, ${completer('taskDefinitionId').accessToken}).

      nested entities 4

    • У полі X-Digital-Signature source вкажіть джерело цифрового підпису.

    • У полі X-Digital-Signature-Derived source вкажіть джерело системного цифрового підпису.

    • У полі Result variable вкажіть назву змінної процесу, до якої необхідно записати результат (за замовчуванням — response).

    nested entities 5

Особливості використання та налаштування делегата Create nested entities in data factory у бізнес-процесі дивіться за посиланням.

2.2.8. Визначення статусу бізнес-процесу (Define business process status)

Перш за все, переконайтеся, що папка /element-templates містить файл defineBusinessProcessStatusDelegate.json.

  • Відкрийте Service Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Status вкажіть статус, що відображатиметься після завершення процесу.

bp element temp 9

2.2.9. Видалення сутності з фабрики даних (Delete entity from data factory)

Перш за все, переконайтеся, що папка /element-templates містить файл dataFactoryConnectorDeleteDelegate.json.

  • Відкрийте Service Task, натисніть кнопку Open Catalog та оберіть шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Resource вкажіть ресурс.

  • У полі Payload введіть дані для створення.

  • У полі X-Access-Token source зазначте токен доступу до системи користувача, під яким виконується операція.

  • У полі X-Digital-Signature source вкажіть джерело цифрового підпису.

  • У полі X-Digital-Signature-Derived source вкажіть джерело системного цифрового підпису.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 10

Перш за все, переконайтеся, що папка /element-templates містить файл digitalSignatureConnectorDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Payload введіть дані для підпису.

  • У полі X-Access-Token source введіть токен доступу до системи користувача, під яким виконується операція.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 11

2.2.11. Отримання ролі з Keycloak (Get roles from Keycloak)

Перш за все, переконайтеся, що папка /element-templates містить файл getRolesFromKeycloak.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (наприклад, rolesOutput).

bp element temp 12

2.2.12. Отримання детальної інформації за суб’єктом з ЄДР (Get subject detail EDR Registry)

Перш за все, переконайтеся, що папка /element-templates містить файл subjectDetailEdrRegistryConnectorDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Authorization token вкажіть токен для доступу до СЕВ ДЕІР «Трембіта».

  • Поле Id визначає змінну, де зберігається код для пошуку в у зовнішньому реєстрі (ЄДР).

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 13

2.2.13. Читання сутності із фабрики даних (Read entity from data factory)

Перш за все, переконайтеся, що папка /element-templates містить файл dataFactoryConnectorReadDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Resource вкажіть ресурс.

  • У полі Resource id введіть ідентифікатор ресурсу.

  • У полі X-Access-Token source вкажіть токен доступу до системи користувача, під яким виконується операція.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 17

2.2.14. Читання користувацьких налаштувань (Read user settings)

Перш за все, переконайтеся, що папка /element-templates містить файл userSettingsConnectorReadDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі X-Access-Token source зазначте токен доступу до системи користувача, під яким виконується операція.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 19

2.2.15. Видалення ролі у користувача Keycloak (Remove role from Keycloak user)

Перш за все, переконайтеся, що папка /element-templates містить файл removeRoleFromKeycloakUser.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі User name вкажіть ідентифікатор користувача у Keycloak.

  • У полі Role зазначте роль користувача.

bp element temp 21

2.2.16. Пошук посадових осіб у Keycloak за їх атрибутами

Розширення Get users by attributes from keycloak — делегат ${getUsersByAttributesFromKeycloak}, для якого імплементовано однойменний шаблон Get users by attributes from keycloak, представлений у вигляді JSON-файлу getUsersByAttributesFromKeycloak.json.

Делегат потрібний для того, щоб при виконанні бізнес-процесу отримувати список користувачів (посадових осіб) за певними атрибутами із сервісу керування ідентифікацією та доступом Keycloak.

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить файл getUsersByAttributesFromKeycloak.json.
Налаштування шаблону

  1. Змоделюйте нову задачу.

  2. Визначте її тип, натиснувши іконку ключа та обравши з меню пункт Service Task (сервісна задача).

    element temp keycloak attributes delegate 1

  3. Перейдіть до панелі налаштувань справа та застосуйте делегат Get users by attributes from keycloak. Для цього оберіть відповідний шаблон із каталогу (Open Catalog) та натисніть Apply для підтвердження.

    element temp keycloak attributes delegate 2

    element temp keycloak attributes delegate 3

  4. Виконайте подальші налаштування:

    • У полі Name вкажіть назву задачі. Наприклад, Отримати список користувачів із Keycloak.

    • У полі Edrpou attribute value вкажіть значення атрибута edrpou. Наприклад, 11111111.

      Значення атрибута edrpou є обов’язковим для заповнення. Його можна передати як напряму (тобто ввести код ЄДРПОУ, наприклад, 11111111), так і через функцію submission(), вказавши ID останньої користувацької задачі (наприклад, 'userTaskId').

    • У полі Drfo attribute value вкажіть значення атрибута drfo. Наприклад, 2222222222.

      Значення атрибута drfo є опціональним. Його можна передати як напряму (тобто ввести код ДРФО, наприклад, 2222222222), так і через функцію submission(), вказавши ID останньої користувацької задачі (наприклад, 'userTaskId').

    • У полі Result variable вкажіть назву змінної, до якої необхідно зберегти відповідь — usersByAttributes.

      В результаті запита отримуємо список користувачів із Keycloak за їх атрибутами, який зберігатиметься у змінній usersByAttributes.

      • Якщо користувач передає лише значення параметра edrpou, то сервіс повертає список усіх посадових осіб відповідної організації.

      • Якщо користувач передає значення параметрів edrpou та drfo, то сервіс повертає список з іменем конкретної посадової особи відповідної організації.

      element temp keycloak attributes delegate 4

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

2.2.17. Пошук отримувачів послуг у Keycloak за їх атрибутами (Get citizen users by attributes from keycloak)

Розширення Get citizen users by attributes from keycloak — делегат ${getCitizenUsersByAttributesFromKeycloak}, для якого імплементовано однойменний шаблон Get citizen users by attributes from keycloak, представлений у вигляді JSON-файлу getCitizenUsersByAttributesFromKeycloak.json.

Делегат потрібний для того, щоб при виконанні бізнес-процесу отримувати список користувачів (отримувачів послуг) за певними атрибутами із сервісу керування ідентифікацією та доступом Keycloak.

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить файл getCitizenUsersByAttributesFromKeycloak.json.

Налаштування шаблону:

  1. Змоделюйте нову задачу.

  2. Визначте її тип, натиснувши іконку ключа та обравши з меню пункт Service Task (сервісна задача).

    e mail notification 04

  3. Перейдіть до панелі налаштувань справа та застосуйте делегат Get citizen users by attributes from keycloak. Для цього оберіть відповідний шаблон із каталогу (Open Catalog) та натисніть Apply для підтвердження.

    e mail notification 05

  4. Виконайте подальші налаштування:

    • У полі Name вкажіть назву задачі. Наприклад, Отримати список отримувачів послуг із Keycloak.

    • У полі Edrpou attribute value вкажіть значення атрибута edrpou. Наприклад, 11111111.

      Значення атрибута edrpou є обов’язковим для заповнення. Його можна передати як напряму (тобто ввести код ЄДРПОУ, наприклад, 11111111), так і через функцію submission(), вказавши ID останньої користувацької задачі (наприклад, userTaskId).

    • У полі Drfo attribute value вкажіть значення атрибута drfo. Наприклад, 2222222222.

      Значення атрибута drfo є опціональним. Його можна передати як напряму (тобто ввести код ДРФО, наприклад, 2222222222), так і через функцію submission(), вказавши ID останньої користувацької задачі (наприклад, 'userTaskId').

    • У полі Result variable вкажіть назву змінної, до якої необхідно зберегти відповідь — citizenUsersByAttributes.

      В результаті запита отримуємо список користувачів із Keycloak за їх атрибутами, який зберігатиметься у змінній citizenUsersByAttributes.

      • Якщо користувач передає лише значення параметра edrpou, то сервіс повертає список усіх отримувачів послуг відповідної організації.

      • Якщо користувач передає значення параметрів edrpou та drfo, то сервіс повертає список з іменем конкретного отримувача послуг відповідної організації.

    e mail notification 06

2.2.18. Пошук сутностей у фабриці даних (Search for entities in data factory)

Перш за все, переконайтеся, що папка /element-templates містить файл dataFactoryConnectorSearchDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Resource вкажіть ресурс.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response.

  • У полі X-Access-Token source вкажіть токен доступу до системи користувача, під яким виконується операція.

bp element temp 22

2.2.19. Пошук суб’єкта в ЄДР (Search subjects EDR Registry)

Перш за все, переконайтеся, що папка /element-templates містить файл searchSubjectsEdrRegistryConnectorDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Authorization token вкажіть токен для доступу до СЕВ ДЕІР «Трембіта».

  • Поле Code визначає змінну, де зберігається код для пошуку в ЄДР.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 23

2.2.20. Надсилання системної помилки (Throw system error)

Перш за все, переконайтеся, що папка /element-templates містить файл camundaSystemErrorDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Message зазначте текст помилки, що буде показано.

bp element temp 24

2.2.21. Надсилання помилки перевірки правдивості (Throw validation error)

Перш за все, переконайтеся, що папка /element-templates містить файл userDataValidationErrorDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У випадному списку Validation errors:

    • зазначте у полі Variable Assignment Type тип змінної, вказавши значення List;

    • натисніть Add Value та у полі Value вкажіть значення помилки, що відображатиметься.

Приклад
{"field": "laboratory", "value": "${submission('start_event').formData.prop('laboratory').prop('laboratoryId').value()}", "message": "Статус в ЄДР "Скаcовано" або "Припинено"}.

bp element temp 25

2.2.22. Оновлення сутності у Фабриці даних (Update entity in data factory)

Перш за все, переконайтеся, що папка /element-templates містить файл dataFactoryConnectorUpdateDelegate.json.

  • Відкрийте Service Task → у вікні справа натисніть кнопку Open Catalog та оберіть відповідний шаблон (Template) зі списку.

  • У полі Name вкажіть назву задачі.

  • У полі Resource вкажіть ресурс.

  • У полі Resource id вкажіть ідентифікатор ресурсу.

  • У полі Payload зазначте дані для створення.

  • У полі X-Access-Token source введіть токен доступу до системи користувача, під яким виконується операція.

  • У полі X-Digital-Signature source вкажіть джерело для Ceph-документа, де зберігається підпис користувача, накладений на дані UI-форми при внесенні.

  • У полі X-Digital-Signature-Derived source вкажіть джерело для Ceph-документа, де зберігається системний підпис, автоматично накладений на тіло запита.

  • У полі Result variable вкажіть будь-яке ім’я для вихідного параметра (за замовчуванням — response).

bp element temp 26

2.2.23. Часткове оновлення сутності у Фабриці даних (Update entity in data factory partially)

Розширення Update entity in data factory partially — делегат для часткового оновлення сутності у фабриці даних, який налаштовується за допомогою розробленого однойменного шаблону Update entity in data factory partially (dataFactoryConnectorPartialUpdateDelegate.json).

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить файл dataFactoryConnectorPartialUpdateDelegate.json.

  1. Створіть Service Task.

  2. На панелі налаштувань справа натисніть кнопку Open Catalog, оберіть відповідний шаблон Update entity in data factory partially зі списку та натисніть Apply для підтвердження.

    partial update 1

  3. Сконфігуруйте обраний шаблон:

    • У полі Name вкажіть назву задачі. Наприклад, Часткове оновлення виконанно.

    • У полі Resource вкажіть ресурс, тобто назву ендпоінту, до якого необхідно звернутися, — person-profile.

      На рівні API ендпоінт виглядає як /partial/<resource-name>/<resource-id>, де <resource-name> — назва ресурсу, а <resource-id> — ідентифікатор ресурсу у Фабриці даних. У полі Resource необхідно вказати значення між /partial та /<resource-id>, без косої риски (/).

    • У полі Resource id вкажіть ідентифікатор ресурсу, тобто сутності у Фабриці даних, яку необхідно оновити. Наприклад, {id}.

      Ідентифікатор ресурсу визначається у форматі UUID. Його можна передати як змінну, взяту із попередніх задач бізнес-процесу, або напряму — як f7dc68fe-98e1-4d95-b80f-df5ce42cebb9.

    • У полі Payload введіть тіло запита — JSON-структуру із параметрами, які необхідно оновити у Фабриці даних. Наприклад, ${updatePersonPayload}.

    • У полі X-Access-Token введіть токен доступу до ресурсу. Наприклад, ${completer('signEditedPersonalProfile').accessToken}.

      Токен доступу береться з АБО ініціатора (наприклад, $initiator().accessToken}), АБО виконавця останньої користувацької задачі (наприклад, ${completer('taskDefinitionId').accessToken}).

    • У полі X-Digital-Signature source вкажіть джерело для Ceph-документа, де зберігається підпис користувача, накладений на дані UI-форми при внесенні, — ${sign_submission('signEditedPersonalProfile').signatureDocumentId}.

    • У полі X-Digital-Signature-Derived source вкажіть джерело для Ceph-документа, де зберігається системний підпис, автоматично накладений на тіло запита, — ${updatePersonPayloadDerivedKey}.

    • У полі Result variable вкажіть назву змінної процесу, до якої необхідно записати результат (за замовчуванням — response).

    partial update 2

Особливості використання та налаштування делегата Update entity in data factory partially у бізнес-процесі дивіться за посиланням.

2.2.24. Конектор до фабрики даних (Connect to data factory)

Розширення Connect to data factory — загальний делегат для інтеграції бізнес-процесів із Фабрикою даних, який налаштовується за допомогою розробленого однойменного шаблону Connect to data factory (dataFactoryConnectorDelegate.json).

Завдяки цьому делегату можна надіслати будь-який запит до будь-якого АРІ-ендпоінту для отримання будь-яких даних. Тобто можна використати для запита будь-яку точку інтеграції (ендпоінт), розроблену на рівні Фабрики даних, яка відображена у REST API реєстру, тобто у Swagger UI.

Один цей загальний делегат здатен замінити усі інші делегати конкретного призначення.
Делегат підтримує взаємодію із HTTP-методами, а саме:

  • POST — для створення сутності/ресурсу. Відповідає БД-операції CREATE.

  • GET  — для пошуку або читання даних. Відповідає БД-операції READ.

  • PUT  — для оновлення сутності. Відповідає БД-операції UPDATE.

  • DELETE — для видалення сутності. Відповідає БД-операції DELETE).

  • PATCH  — для часткового оновлення (модифікації) сутності. Відповідає БД-операції UPDATE.

whats new 1 6 15

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить файл dataFactoryConnectorDelegate.json.
Ця інструкція розглядає випадки взаємодії делегата з різними типами ендпоінтів на прикладі сутності ownership (право власності).
2.2.24.1. Налаштування взаємодії з POST-ендпоінтом

HTTP-метод POST використовується для створення сутності/ресурсу в базі даних реєстру.

Для налаштування шаблону делегата в Camunda Modeler, необхідно виконати наступні кроки:

  1. Створіть Service Task.

  2. На панелі налаштувань справа натисніть кнопку Open Catalog, оберіть відповідний шаблон Connect to data factory зі списку та натисніть Apply для підтвердження.

    connect to data factory delegate 1

  3. Сконфігуруйте обраний шаблон:

    • У полі Name вкажіть назву задачі. Наприклад, Створити сутність (POST).

    • Розгорніть блок Method у секції Custom Fields та оберіть з випадного списку HTTP-метод POST для взаємодії з Фабрикою даних.

      connect to data factory delegate 2

    • Розгорніть блок Path та вкажіть шлях до ресурсу у Фабриці даних, тобто назву ендпоінту, до якого необхідно звернутися:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для ендпоінту.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value вкажіть ендпоінт — /ownership.

        Назву ендпоінту необхідно вказувати через косу риску (/) як префікс.

      connect to data factory delegate 3

    • Метод POST не вимагає додаткових request-параметрів, окрім тіла запита, а отже блок Request parameters залиште порожнім.

      connect to data factory delegate 4

    • Розгорніть блок Payload та вкажіть вхідні параметри, тобто тіло запита:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для тіла запита.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть тіло запита — JSON-структуру із параметрами, які необхідно записати до БД. Наприклад, ${payload}.

        У нашому прикладі ми передаємо змінну ${payload}, до якої були збережені дані в одній із попередніх задач бізнес-процесу.

        Приклад 2. Схема тіла запита згідно з REST API реєстру
        {
  "ownershipId": "b45b90c0-c53d-4fd3-aa82-02e8e7392345",
  "code": "string",
  "name": "string"
}

      connect to data factory delegate 5

    • Розгорніть блок X-Access-Token та вкажіть введіть токен доступу до ресурсу:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для токена доступу.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть токен доступу. Наприклад, ${completer('taskId').accessToken}.

        Токен доступу береться з АБО ініціатора (наприклад, $initiator().accessToken}), АБО виконавця останньої користувацької задачі (наприклад, ${completer('taskDefinitionId').accessToken}).

      connect to data factory delegate 6

    • Розгорніть блок X-Digital-Signature source та вкажіть джерело для Ceph-документа, де зберігається підпис користувача (КЕП), накладений на дані UI-форми при внесенні:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для КЕП.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value вкажіть підпис користувача (КЕП). Наприклад, ${sign_submission('taskId').signatureDocumentId}.

        У нашому прикладі ми передаємо КЕП із користувацької форми, де його застосовано, через функцію sign_submission() (детальніше про використання JUEL-функцій у бізнес-процесах — за посиланням.)

      connect to data factory delegate 7

    • Розгорніть блок X-Digital-Signature-Derived source та вкажіть джерело для Ceph-документа, де зберігається системний підпис, автоматично накладений на тіло запита:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для системного підпису.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value передайте системний підпис. Наприклад, `${createPersonPayloadDerivedKey}.

        У нашому прикладі ми передаємо змінну ${createPersonPayloadDerivedKey}, до якої було збережено системний підпис в одній із попередніх задач бізнес-процесу.

      connect to data factory delegate 8

    • Розгорніть блок Result variable та вкажіть назву змінної процесу, до якої необхідно записати результат (за замовчуванням — response):

      • Активуйте позначку Local Variable Assignment → ON.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть назву результівної змінної (за замовчуванням — response).

        Сервіс не повертає тіла у відповідь на POST-запит. В результаті повертається лише код відповіді та його опис.

        Приклад 3. Код відповіді та його опис згідно з REST API реєстру
        201
OK, ресурс успішно створено

    connect to data factory delegate 9

2.2.24.2. Налаштування взаємодії з GET-ендпоінтом

HTTP-метод GET використовується для отримання даних сутності (SELECT за id із таблиці в БД) або пошуку даних за певними критеріями (SELECT із представлення (view)) в базі даних реєстру. Використовується для отримання об’єктів. Не змінює стан ресурсу.

КЕП і системний підпис не використовуються при GET-запиті.
Отримання даних сутності за id

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

Для налаштування шаблону делегата в Camunda Modeler, необхідно виконати наступні кроки:

  1. Створіть Service Task.

  2. На панелі налаштувань справа натисніть кнопку Open Catalog, оберіть відповідний шаблон Connect to data factory зі списку та натисніть Apply для підтвердження.

    connect to data factory delegate 1

  3. Сконфігуруйте обраний шаблон:

    • У полі Name вкажіть назву задачі. Наприклад, Отримати сутніть за id (GET).

    • Розгорніть блок Method у секції Custom Fields та оберіть з випадного списку HTTP-метод GET для взаємодії з Фабрикою даних.

      connect to data factory delegate 10

    • Розгорніть блок Path та вкажіть шлях до ресурсу у Фабриці даних, тобто назву ендпоінту, до якого необхідно звернутися:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для ендпоінту.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value вкажіть ендпоінт. Наприклад, /ownership/${response.value.responseBody.prop('id).value()}.

        Назву ендпоінту необхідно вказувати через косу риску (/) як префікс.

        Обов’язково необхідно передати ідентифікатор сутності. ID можна передати декількома способами. Наприклад:

        • через змінну як ${response.value.responseBody.prop('id).value()};

        • через змінну як /${id};

        • через функцію submission() як ${submission('taskId').formData.prop('id').value()}

        • через константне значення UUID напряму — /b45b90c0-c53d-4fd3-aa82-02e8e7392345.

        connect to data factory delegate 11

    • Цей випадок не вимагає додаткових request-параметрів, окрім параметрів шляху (path params), а отже блоки Request parameters та Payload залиште порожніми.

    • Розгорніть блок X-Access-Token та вкажіть введіть токен доступу до ресурсу:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для токена доступу.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть токен доступу. Наприклад, ${completer('taskId').accessToken}.

        Токен доступу береться з АБО ініціатора (наприклад, $initiator().accessToken}), АБО виконавця останньої користувацької задачі (наприклад, ${completer('taskDefinitionId').accessToken}).

        connect to data factory delegate 12

    • Розгорніть блок Result variable вкажіть назву змінної процесу, до якої необхідно записати результат (за замовчуванням — response):

      • Активуйте позначку Local Variable Assignment → ON.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть назву результівної змінної (за замовчуванням — response).

        У відповідь на GET-запит сервіс повертає ресурс за його ID.

        Приклад 4. Приклад тіла відповіді згідно з REST API реєстру
        {
  "ownershipId": "b45b90c0-c53d-4fd3-aa82-02e8e7392345",
  "code": "string",
  "name": "string"
}

        connect to data factory delegate 13

Пошук даних за критеріями

Цей випадок описує приклад отримання списку ресурсів через запит до ендпоінту, що згенерований на базі відповідного представлення (Search Condition) у Фабриці даних.

Для налаштування шаблону делегата в Camunda Modeler, необхідно виконати наступні кроки:

  1. Створіть Service Task.

  2. На панелі налаштувань справа натисніть кнопку Open Catalog, оберіть відповідний шаблон Connect to data factory зі списку та натисніть Apply для підтвердження.

    connect to data factory delegate 1

  3. Сконфігуруйте обраний шаблон:

    • У полі Name вкажіть назву задачі. Наприклад, Пошук даних за критеріями (GET).

    • Розгорніть блок Method у секції Custom Fields та оберіть з випадного списку HTTP-метод GET для взаємодії з Фабрикою даних.

      connect to data factory delegate 14

    • Розгорніть блок Path та вкажіть шлях до ресурсу у Фабриці даних, тобто назву ендпоінту, до якого необхідно звернутися:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для ендпоінту.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value вкажіть ресурс. Наприклад, /staff-equal-constant-code.

        • Назва ресурсу відповідає назві ендпоінту для Search Condition у Фабриці даних.

        • Назву ресурсу необхідно вказувати через косу риску (/) як префікс.

        connect to data factory delegate 15

    • Цей випадок вимагає налаштування додаткових параметрів запита — query-параметрів. Розгорніть блок Request parameters та вкажіть query-параметри як пари ключ-значення (Map).

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну ендпоінту для Search Condition.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — Map.

      • У полі Variable Assignment Value введіть ключ пошуку — constantCode та його значення — ${submission('formId').formData.prop('staffStatusCode').value()}.

        У нашому випадку значення ключа пошуку constantCode передається через функцію submission() (детальніше про використання JUEL-функцій у бізнес-процесах — за посиланням.). Інші параметри є опціональними.

        Приклад 5. Приклад query-параметрів запита у форматі JSON згідно з REST API реєстру
        {
"offset": 0,
"constantCode": "string",
"limit": 0
}

        connect to data factory delegate 16

    • Розгорніть блок X-Access-Token та вкажіть введіть токен доступу до ресурсу:

      • Активуйте позначку Local Variable Assignment → ON. Це дозволить створити локальну змінну для токена доступу.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть токен доступу. Наприклад, ${completer('taskId').accessToken}.

        Токен доступу береться з АБО ініціатора (наприклад, $initiator().accessToken}), АБО виконавця останньої користувацької задачі (наприклад, ${completer('taskDefinitionId').accessToken}).

        connect to data factory delegate 17

    • Розгорніть блок Result variable вкажіть назву змінної процесу, до якої необхідно записати результат (за замовчуванням — response):

      • Активуйте позначку Local Variable Assignment → ON.

      • У полі Variable Assignment Type оберіть з випадного списку тип призначення змінної — String or Expression.

      • У полі Variable Assignment Value введіть назву результівної змінної (за замовчуванням — response).

        У відповідь на GET-запит сервіс повертає масив об’єктів/ресурсів за критеріями пошуку.

        Приклад 6. Приклад тіла відповіді від сервісу згідно з REST API реєстру
        [
  {
    "staffStatusId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "constantCode": "string",
    "name": "string"
  }
]

        connect to data factory delegate 18

2.2.24.3. Налаштування взаємодії з PUT-ендпоінтом

HTTP-метод PUT використовується для оновлення сутності/ресурсу в базі даних реєстру. Використовується для зміни наявного ресурсу за вказаним ID.

Принцип налаштування делегата для оновлення сутності є ідентичним до Налаштування взаємодії з POST-ендпоінтом за декількома винятками:

  • Розгорніть блок Method у секції Custom Fields та оберіть з випадного списку HTTP-метод PUT для взаємодії з Фабрикою даних.

    connect to data factory delegate 19

  • У блоці Path вкажіть ендпоінт /ownership/${response.value.responseBody.prop('id).value()} як локальну зміну із зазначенням ідентифікатора ресурсу, який необхідно оновити.

    connect to data factory delegate 20

    У нашому випадку ми передаємо значення id як змінну ${response.value.responseBody.prop('id).value()} (детальніше про опції передачі id ви можете переглянути у розділі Налаштування взаємодії з GET-ендпоінтом).

  • У блоці Result variable до результівної змінної зберігається такий код відповіді:

Приклад 7. Код відповіді та його опис згідно з REST API реєстру
204 OK
2.2.24.4. Налаштування взаємодії з DELETE-ендпоінтом

HTTP-метод DELETE використовується для видалення сутності/ресурсу в базі даних реєстру. Використовується для видалення ресурсу за вказаним ID.

Принцип налаштування делегата для видалення сутності є ідентичним до Налаштування взаємодії з PUT-ендпоінтом за двома винятками:

  • У блоці Method вкажіть метод DELETE як локальну змінну.

    connect to data factory delegate 21

  • Видалення сутності не потребує визначення параметрів тіла запита, а тому залиште блок Payload порожнім.

    connect to data factory delegate 21 1
2.2.24.5. Налаштування взаємодії з PATCH-ендпоінтом

HTTP-метод PATCH використовується для часткового оновлення сутності/ресурсу в базі даних реєстру. Використовується для модифікації конкретних параметрів ресурсу за вказаним ID.

Принцип налаштування делегата для часткового оновлення сутності є ідентичним до Налаштування взаємодії з PUT-ендпоінтом за одним винятком:

  • Розгорніть блок Method у секції Custom Fields та оберіть з випадного списку HTTP-метод PATCH для взаємодії з Фабрикою даних.

    connect to data factory delegate 22

2.2.25. Інтеграція із зовнішніми системами (Connect to external system v2)

Бізнес-назва інтеграційного розширення: Connect to external system v2.

Службова назва інтеграційного розширення: ${externalSystemConnectorDelegateV2}.

Назва файлу у бібліотеці розширень: externalSystemConnectorDelegateV2.json.

Загальне інтеграційне розширення-делегат, також відоме як REST Connector, надає можливість взаємодіяти із зовнішніми системами через REST API й налаштовується у сервісних задачах (Service Task) бізнес-процесу за допомогою шаблону Connect to external system v2.

При налаштуванні делегата у додатку Camunda Modeler, переконайтеся, що папка із застосунком resources > element-templates містить файл externalSystemConnectorDelegateV2.json.
Детальніше про застосування REST-конектора у бізнес-процесах ви можете переглянути на сторінці Інтеграція із зовнішніми сервісами за допомогою REST-конектора.

2.3. Типові розширення для задач на відправлення повідомлень (Send Task)

2.3.1. Відправлення повідомлень користувачу (Send User Notification)

Розширення Send User Notification — делегат для відправлення повідомлень отримувачам послуг електронною поштою, з використанням заданого шаблону в HTML-вигляді.

Делегат застосовується до задач типу Send Task.

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить sendUserNotification.json

Для налаштування шаблону виконайте наступні кроки:

  1. Створіть Send Task.

    e mail notification 02

  2. На панелі налаштувань справа натисніть кнопку Open Catalog та оберіть шаблон (template) делегата — Send User Notification. Для підтвердження натисніть Apply.

    e mail notification 03

  3. Виконайте подальші налаштування:

    • У полі name вкажіть назву задачі (наприклад, Відправка email користувачу).

    • У полі Recipient вкажіть унікальний ідентифікатор — <username> отримувача повідомлення (наприклад, ${initiator().userName}).

    • У полі Subject вкажіть текстову назву теми повідомлення (наприклад, Email successfully generated).

    • У полі Notification message template — вкажіть унікальну назву FreeMarker-шаблону для формування тіла повідомлення, яка відповідає назві директорії шаблону відповідно до структури <registry-regulation>/notifications/<channel>/<template_name>/*.* (наприклад, add-lab-template).

    • У полі Notification template model — вкажіть набір даних для генерації тіла повідомлення на базі шаблону (наприклад, ${templateModel}).

2.4. Типові розширення для виклику глобальних підпроцесів (Call Activity)

Каталог розроблених шаблонів для налаштування делегатів зберігається у сховищі коду Gerrit, в окремому репозиторії business-process-modeler-extensions → element-templates.
Особливості використання Call Activity у бізнес-процесах дивіться за посиланням.

2.4.1. Делегат виклику глобального підпроцесу (Call Activity)

Розширення Call Activity — загальний делегат для виклику глобального підпроцесу, що налаштовується за допомогою розробленого однойменного шаблону Call Activity (callActivity.json).

Розширення використовується, коли необхідно з одного бізнес-процесу викликати зовнішній підпроцес.

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить файл callActivity.json.

Існують певні обмеження щодо кількості рівнів вкладеності бізнес-процесів при викликах зовнішніх підпроцесів за допомогою делегата Call Activity.

Для правильної роботи функціональності виклику зовнішніх підпроцесів через Call Activity, використовуйте не більше 3-х рівнів вкладеності бізнес-процесів, тобто основний процес, глобальний підпроцес 1-го рівня та глобальний підпроцес 2-го рівня.
Налаштування шаблону

  1. Створіть Call Activity.

    element temp call activity 1

  2. На панелі налаштувань справа натисніть кнопку Open Catalog, оберіть відповідний шаблон Call Activity зі списку та натисніть Apply для підтвердження.

    element temp call activity 2

    element temp call activity 3

  3. Виконайте подальші налаштування:

    • У полі Name вкажіть назву задачі (наприклад, call-activity-task).

    • У полі Called Element вкажіть ідентифікатор стороннього процесу або підпроцесу, що викликатиметься (наприклад, called-process).

    • У полі Input data вкажіть вхідні дані, які необхідно передати бізнес-процесу, що викликається. Параметри мають передаватися у вигляді пар ключ-значення (наприклад, ${payload}).

    • У полі Output variable name вкажіть назву змінної, до якої необхідно записати дані (payload), отримані в результаті виконання підпроцесу, що викликається (наприклад, callActivityOutput).

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

      element temp call activity 4

2.4.2. Делегат виклику підпроцесу для перевірки статусу витягу (Check excerpt status)

Розширення Check excerpt status — специфікований делегат для виклику підпроцесу перевірки статусу витягу, що налаштовується за допомогою розробленого однойменного шаблону Check excerpt status (checkExcerptStatusCallActivity.json).

Перед налаштуванням шаблону в Сamunda Modeler переконайтеся, що папка із застосунком resources → element-templates містить файл checkExcerptStatusCallActivity.json.
Налаштування шаблону

  1. Створіть Call Activity.

    element temp call activity 1

  2. На панелі налаштувань справа натисніть кнопку Open Catalog, оберіть відповідний шаблон Check excerpt status зі списку та натисніть Apply для підтвердження.

    element temp call activity 2

    element temp call activity check excerpt status 1

  3. Виконайте подальші налаштування:

    • У полі Name вкажіть назву задачі (наприклад, call-activity-task).

    • У полі Input excerpt identifier вкажіть ID витягу, який необхідно передати бізнес-процесу, що викликається (наприклад, ${excerptIdentifier}).

    • У полі Output variable name вкажіть назву змінної, до якої необхідно зберегти статус витягу, отриманий в результаті виконання підпроцесу, що викликається (наприклад, excerptStatusOutput).

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

      element temp call activity check excerpt status 2

Всі інші атрибути, як то Called Element, CallActivity Type тощо, необхідні для налаштування Call Activity вручну, без використання шаблону, визначаються автоматично, "під капотом".
1. Делегат (англ. Delegate) — клас, який дозволяє зберігати в собі посилання на метод із певною сигнатурою (порядком і типами значень, що приймаються та повертається) довільного класу. Екземпляри делегатів містять посилання на конкретні методи конкретних класів.
2. В системі DNS можна задавати запис за замовчуванням для неоголошених піддоменів. Такий запис називається wildcard.