Самостійна реєстрація користувачів з ручною модерацією

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

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

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

Бізнес-процес складається з двох пулів, що представляють двох учасників: посадову особу-заявника, яка самореєструється, та модератора, який перевіряє дані. Обмін інформацією між учасниками здійснюється через події повідомлень (Message events).

Заявник вводить особисті дані на формі, які надсилаються модератору для перевірки. Модератор має певний час (тут — 2 хвилини) на прийняття рішення, контрольоване таймером (Timer boundary event). Якщо рішення не прийнято вчасно, процес іде за альтернативним потоком та завершується, а користувач не реєструється.

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

При позитивному рішенні, інформація передається на сервісну задачу із делегатом Save user roles, який змінює роль користувача з unregistered-officer на officer. Таким чином, користувач реєструється в системі.

Заявник переходить на форму із повідомленням про успішну самореєстрацію та статусом “Самореєстрацію пройдено”. Після цього заявник перенаправляється на форму для повторного входу в систему.

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

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

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

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

2.1. Увімкнення опції самореєстрації посадових осіб

Активуйте опцію самореєстрації надавачів послуг в адміністративній панелі Control Plane.

Детальніше про це — див. на сторінці Налаштування автореєстрації для посадових осіб.

2.2. Моделювання структур даних

Створіть модель даних реєстру за прикладом нижче.

Приклад .xml-схеми ви можете знайти у регламенті демо-реєстру consent-data за посиланням: https://admin-tools-consent-data.apps.envone.dev.registry.eua.gov.ua/gerrit.

Схема буде доступна за назвою tablesOfficers.xml.
Референтний приклад моделі даних. Таблиці для збереження самореєстрованих користувачів 
<changeSet author="registry owner" id="table officers">
        <createTable tableName="officers" ext:historyFlag="true" remarks="Перелік посадових осіб">
            <column name="officers_id" type="UUID" defaultValueComputed="uuid_generate_v4()">
                <constraints nullable="false" primaryKey="true" primaryKeyName="pk_officers_id"/>
            </column>
            <column name="user_name" type="TEXT" remarks="username користувача в Keycloak">
                <constraints nullable="false"/>
            </column>
            <column name="full_name" type="TEXT" remarks="ПІБ користувача">
                <constraints nullable="false"/>
            </column>
            <column name="drfo" type="TEXT" remarks="РНОКПП користувача">
                <constraints nullable="false"/>
            </column>
            <column name="edrpou" type="TEXT" remarks="ЄДРПОУ користувача">
                <constraints nullable="false"/>
            </column>
            <column name="realm_roles" type="TEXT" remarks="Перелік регламентних ролей користувача"/>
            <column name="work_start_date" type="DATE" remarks="Дата прийняття на роботу"/>
            <column name="unit_name" type="TEXT" remarks="Назва підрозділу згідно ієрархії"/>
            <column name="hierarchy_code" type="TEXT" remarks="Сурогатний ключ, складений на основі structure_code"/>
            <column name="structure_code" type="TEXT" remarks="Унікальний код ієрархії для відповідного підрозділу"/>
            <column name="selfregistration_decision" type="BOOLEAN" remarks="Рішення модератора щодо самореєстрації"/>
        </createTable>
    </changeSet>

Ця модель даних створює таблицю officers у базі даних, яка зберігає інформацію про зареєстрованих користувачів (посадових осіб), які самореєструвалися в системі.

Опис стовпців таблиці

  • officers_id — це первинний ключ таблиці з унікальним ідентифікатором кожного посадовця, типом UUID, який автоматично генерується за допомогою функції uuid_generate_v4().

  • user_name — імена користувача з системи Keycloak (система управління ідентифікацією та доступом користувачі).

  • full_name — ПІБ користувача.

  • drfo — РНОКПП користувача (Реєстраційний номер облікової картки платника податків).

  • edrpou — ЄДРПОУ користувача (Єдиний державний реєстр підприємств та організацій України).

  • realm_roles — перелік регламентних ролей користувача.

  • work_start_date — дата прийняття користувача на роботу.

  • unit_name — назва підрозділу відповідно до ієрархії організації.

  • hierarchy_code — сурогатний ключ, складений на основі structure_code.

  • structure_code — унікальний код ієрархії для відповідного підрозділу.

  • selfregistration_decision — булеве значення, що відображає рішення модератора щодо самореєстрації користувача.

3. Референтний приклад процесу

Приклад .bpmn-моделі процесу, а також користувацькі .json-форми до нього ви можете знайти у регламенті демо-реєстру consent-data за посиланням: https://admin-tools-consent-data.apps.envone.dev.registry.eua.gov.ua/gerrit.

Процес буде доступний за назвою officer-selfregistration-handmoderation.bpmn. Назви форм ви можете знайти всередині відповідних користувацьких задач бізнес-процесу у полі Form key.

3.1. Створення пулів для учасників процесу

Створіть два пули (Participant) для учасників процесу — посадової особи-заявника, яка самореєструється, та модератора, який перевіряє дані.

officer self register manual mod 1
Зображення 1. Пул процесу для посадової особи-заявника, який самореєструється
officer self register manual mod 2
Зображення 2. Пул процесу для посадової особи-модератора, який перевіряє дані

Вкажіть для кожного наступне:

  • Participant Name — назва пулу для процесу.

  • Process ID — ідентифікатор процесу в регламенті реєстру.

  • Process name — бізнес-назва процесу.

  • Активуйте чекбокс Executable.

3.2. Початок процесу

Змоделюйте стартову подію. Ця подія ініціює автоматичний старт процесу після автентифікації з роллю unregistered-officer.

  • Вкажіть назву задачі.

  • Вкажіть ініціатора процесу як initiator.

    Що таке ініціатор?

    "Start initiator = initiator" вказує на те, що значення ініціатора (тобто особи чи системи, яка розпочала процес) буде встановлено як initiator.

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

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

officer self register manual mod 3

3.3. Надсилання даних з токена для підтвердження реєстрації

Змоделюйте проміжну подію відправлення повідомлення — Message Intermediate Throw Event.

Детальніше про Message Intermediate Throw Event ви можете переглянути на сторінці Моделювання та налаштування проміжної події відправки повідомлення.

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

Виконайте налаштування події наступним чином:

  1. У розділі Implementation вкажіть:

    • Тип — Delegate expression.

    • Вираз — ${startProcessByMessageDelegate}. Змінна є імплементацією делегата.

  2. У розділі Global message reference:

    • Оберіть startModerationBpMessage зі списку доступних.

    • У полі Name продублюйте значення startModerationBpMessage для зручності.

  3. У розділі Inputs вкажіть вхідні дані для передачі до іншого процесу:

    • Створіть локальну змінну messagePayload.

    • Визначте для неї тип Map, тобто ключі-значення.

    • Передайте набір ключів-значень як Map entries у полях Key та Value. Зробити це можна наступним чином за допомогою функції initiator():

      • ДРФО/РНОКПП

        • Key: drfo

        • Value: ${initiator().drfo}

      • ДРФО/РНОКПП

        • Key: edrpou

        • Value: ${initiator().edrpou}

      • ПІБ

        • Key: fullName

        • Value: ${initiator().fullName}

      • Ім’я користувача в системі

        • Key: userName

        • Value: ${initiator().userName}

officer self register manual mod 4

3.4. Отримання даних з токена модератором для підтвердження реєстрації

Змоделюйте стартову подію повідомлення — Message Start Event.

Детальніше про Message Start Event ви можете переглянути на сторінці Моделювання та налаштування стартової події повідомлення.

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

Виконайте налаштування події наступним чином:

  1. Визначте ідентифікатор події як start_message_event. Він буде використаний у наступній скрипт-задачі.

  2. У розділі Global message reference:

    • Оберіть startModerationBpMessage зі списку доступних.

    • У полі Name продублюйте значення startModerationBpMessage для зручності.

officer self register manual mod 5

3.5. Скрипт для підготовки даних до відображення на UI-формі

Створіть скрипт-задачу (Script Task) та додайте Groovy-скрипт, який підготує дані для відображення на UI-формі процесу.

officer self register manual mod 6

Відкрийте редактор скриптів та додайте наступний скрипт:

Скрипт для підготовки даних до відображення на UI-формі 
set_transient_variable('payload', S(message_payload('start_message_event').data, 'application/json'))

Цей скрипт виконує наступні дії:

  1. Витягує дані з повідомлення start_message_event та конвертує їх у формат JSON. Для цього використовується функція message_payload('start_message_event').data. Функція S забезпечує обробку JSON-формату.

  2. Після того, як дані перетворено на JSON, скрипт створює тимчасову змінну payload та присвоює їй значення цих даних. Функція set_transient_variable() використовується для створення тимчасової змінної процесу, яка зберігатиме змінну payload.

3.6. Визначення бізнес-ключа процесу

Ця задача — сервісна задача (Service Task), яка використовує делегат Define process business key, що виконує певний код або логіку під час виконання цієї задачі.

Що таке бізнес-ключ?

Бізнес-ключ або Ключ бізнес-процесу (Business Key) — це специфічний для домену ідентифікатор екземпляра бізнес-процесу у Camunda BPM. Він є додатковим атрибутом, що застосовується при моделюванні бізнес-процесів для їх однозначної ідентифікації, а також ідентифікації користувацьких задач процесу.

За допомогою розширення БП задається вхідний параметр businessKey. Цей параметр отримує значення з тимчасової змінної payload, яка була створена раніше, та зокрема з атрибута fullName.

Після виконання цієї задачі, бізнес-ключ процесу буде встановлено як значення fullName із тимчасової змінної payload.

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

${payload.value.prop('fullName').value()}

officer self register manual mod 7

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

3.7. Перегляд даних для реєстрації модератором на UI-формі

Ця задача — користувацька задача (User Task) з ідентифікатором makeDecisionActivity, яка призначена для виконання посадовою особою-модератором (candidateGroups="officer-moderator").

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

За допомогою розширення-делегата User Form задається вхідний параметр Form data pre-population, який отримує значення з тимчасової змінної "payload", визначеної у скрипті раніше. Цей параметр передає дані заявника до форми, який відображається модератору.

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

Виконайте налаштування наступним чином:

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

  2. Застосуйте шаблон делегата — User Form.

  3. У полі ID введіть ідентифікатор задачі — makeDecisionActivity.

  4. У полі Form key визначте ключ для поєднання із відповідною змодельованою формою бізнес-процесу — selfregistration-decision.

  5. У полі Candidate roles введіть роль посадової особи-модератора процесу, визначену у регламенті, — officer-moderator.

  6. У полі Form data pre-population передайте дані на UI-форму як змінну ${payload}.

officer self register manual mod 8

3.8. Таймер для прийняття рішення модератором щодо реєстрації

Це гранична подія (Timer Boundary Event), яка прикріплена до користувацької задачі makeDecisionActivity. Ця подія містить визначення події таймера (timerEventDefinition), яке встановлює таймер із тривалістю 2 хвилини (PT2M).

Коли користувацька задача makeDecisionActivity активується, таймер починає відлік 2 хвилин. Якщо модератор не приймає рішення протягом цього часу, таймер спрацьовує, і процес переходить до наступного кроку відповідно до альтернативного потоку (це означає, що користувач не буде зареєстрований).

Виконайте налаштування наступним чином:

  1. У полі Name вкажіть назву для події.

  2. У розділі Timer:

    • У полі Type (Timer Definition Type) вкажіть тип таймера — Duration (тривалість).

      Детальніше про таймери — дивіться на сторінках:

    • У полі Value вкажіть значення для таймера у певному форматі. Наприклад, PT2M, тобто 2 хвилини.

      Ви можете налаштувати таймер, використовуючи стандартний формат ISO 8601 або cron-вираз.

officer self register manual mod 9

3.9. Надсилання повідомлення про те, що рішення про автореєстрацію не прийнято (альтернативний потік)

Це кінцева подія (Message End Event), яка має визначення події повідомлення (messageEventDefinition) і використовує делегат ${sendMessageDelegate}, що відповідає за надсилання повідомлення.

Детальніше про Message End Event ви можете переглянути на сторінці Моделювання та налаштування кінцевої події повідомлення.

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

Функція process_caller() використовується для отримання інформації про той процес, який викликав поточний процес.

У нашому випадку функція отримує ідентифікатор (id) процесу, який викликав поточний процес. Цей ідентифікатор передається як вхідний параметр correlationProcessInstanceId для делегата sendMessageDelegate, який надсилає повідомлення.

Виконайте налаштування наступним чином:

  1. У розділі Implementation вкажіть:

    • Тип — Delegate expression.

    • Вираз — ${sendMessageDelegate}. Змінна є імплементацією делегата.

  2. У розділі Global message reference:

    • Оберіть decisionOverdueMessage зі списку доступних.

    • У полі Name продублюйте значення decisionOverdueMessage для зручності.

  3. У розділі Inputs вкажіть вхідні дані для передачі до іншого процесу:

    • Створіть локальну змінну correlationProcessInstanceId.

    • Визначте для неї тип String or Expression, тобто рядок або вираз.

    • У полі Value передайте ідентифікатор процесу, який викликав поточний процес. Зробити це можна наступним чином за допомогою функції process_caller():

      ${process_caller().id}

officer self register manual mod 10

3.10. Отримання повідомлення про те, що рішення про автореєстрацію не прийнято (альтернативний потік)

Ця подія є проміжною подією отримання повідомлення (Intermediate Message Catch Event) у процесі BPMN. Вона служить для очікування та перехоплення вхідного повідомлення, яке відправлено іншим процесом або учасником. Зазвичай такі події використовуються для синхронізації або координації між різними процесами чи учасниками у бізнес-процесі.

Детальніше про Intermediate Message Catch Event ви можете переглянути на сторінці Моделювання та налаштування проміжної події отримання повідомлення.
Виконайте налаштування події наступним чином:

У розділі Global message reference:

  1. Оберіть decisionOverdueMessage зі списку доступних.

  2. У полі Name продублюйте значення decisionOverdueMessage для зручності.

officer self register manual mod 11

3.11. Виведення інформації про завершення процесу на форму (альтернативний потік)

Ця задача є користувацькою задачею (User Task) і призначена для надання інформації користувачеві про те, що процес реєстрації завершився через вичерпання часу, відведеного на прийняття рішення.

Ця задача призначена для ініціатора процесу (camunda:assignee="${initiator}"), який є заявником. Форма, пов’язана з цією задачею, має ключ selfregistration-decision-overdue (camunda:formKey="selfregistration-decision-overdue"), який відображає форму з інформацією про завершення процесу по вичерпанню часу.

Виконайте налаштування наступним чином:

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

  2. Застосуйте шаблон делегата для цієї задачі — User Form.

  3. Поєднайте користувацьку задачу із UI-формою за допомогою параметра Form key. Введіть значення selfregistration-decision-overdue.

  4. У полі Assignee вкажіть змінну для особи, якій призначається поточна задача, — ${initiator}.

officer self register manual mod 11 1

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

3.12. Підписання даних КЕП

Ця задача є користувацькою задачею (User Task) у бізнес-процесі BPMN і призначена для підпису рішення заявника за допомогою кваліфікованого електронного підпису (КЕП).

Ця задача призначається для користувача, який виконав задачу makeDecisionActivity. Форма, пов’язана із цією задачею, має ключ selfregistration-sign-decision, який відображає форму для підпису рішення КЕП. Вхідні дані для форми передаються із результатів форми задачі makeDecisionActivity.

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

Виконайте налаштування наступним чином:

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

  2. Застосуйте шаблон делегата — Officer Sign Task.

  3. У полі ID введіть ідентифікатор задачі — signDecisionActivity.

  4. У полі Form key визначте ключ для поєднання із відповідною змодельованою формою бізнес-процесу — selfregistration-sign-decision.

  5. У полі Assignee вкажіть, кому призначається задача для виконання. Використайте для цього функцію completer():

    ${completer('makeDecisionActivity').userName}

  6. У полі Form data pre-population передайте дані на UI-форму через функцію submission():

    ${submission('makeDecisionActivity').formData}.

officer self register manual mod 12

3.13. Підписання даних системним ключем

Ця задача є сервісною задачею (Service Task) у бізнес-процесі BPMN і призначена для підпису даних системним ключем, тобто автоматичним підписом з боку системи.

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

Вхідні параметри для цього завдання включають x_access_token та payload. x_access_token отримується від користувача, який завершив задачу signDecisionActivity, а payload містить дані форми з результатів цього завдання.

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

Виконайте налаштування наступним чином:

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

  2. Використовуйте делегат System signature by DSO service із каталогу шаблонів для накладання системного підпису.

  3. Вхідні дані передайте функцію submission у відповідному полі:

    ${submission('signDecisionActivity').formData}

  4. Передайте токен виконавця останньої користувацької задачі у бізнес-процесі: ${completer('signDecisionActivity').accessToken}.

  5. Відповідь запишіть у змінну subject_system_signature_ceph_key.

officer self register manual mod 13

3.14. Створення запису у базі даних реєстру

Ця задача створює користувача в системній таблиці бази даних реєстру. Вона використовує шаблон делегата dataFactoryConnectorCreateDelegate для виконання дій. Задача отримує вхідні параметри з попередніх задач, такі як ключі та дані форми, та передає їх для створення користувача.

Вхідні параметри включають:

  • x_digital_signature_derived_ceph_key — ключ, що походить від підписаного документа.

  • resource — ресурс, що буде створений (у цьому випадку, officers).

  • x_access_token — токен доступу виконавця задачі signDecisionActivity.

  • x_digital_signature_ceph_key — системний ключ документа із підписом від задачі signDecisionActivity.

  • payload — дані форми з завдання signDecisionActivity.

Виконайте налаштування наступним чином:

  1. Створіть сервісну задачу (Service Task).

  2. Використовуйте делегат Create entity in data factory, щоб створити сутність у базі даних.

  3. Вкажіть ресурс/API-ендпоінт officers, що відповідає назві таблиці із даними, яку ви визначили при створенні моделі даних реєстру — officers.

  4. Вхідні дані передайте через функцію submission() у відповідному полі:

    ${submission('signDecisionActivity').formData}

  5. Передайте токен виконавця останньої користувацької задачі у бізнес-процесі: ${completer('signDecisionActivity').accessToken}.

  6. Вкажіть джерело системного підпису. Для цього використовуйте функцію sign_submission():
    ${sign_submission('signDecisionActivity').signatureDocumentId}.

  7. Вкажіть як змінну ${subject_system_signature_ceph_key} ключ Ceph-документа, який містить інформацію про підписані дані.

  8. Запишіть відповідь до результівної змінної, наприклад, response.

officer self register manual mod 14

3.15. Визначення статусу виконання процесу

Ця задача встановлює результат виконання процесу "Самореєстрацію пройдено" за допомогою шаблону делегата defineBusinessProcessStatusDelegate. Задача приймає вхідні дані з попередньої задачі та передає результат до наступного етапу процесу.

Встановіть результат виконання:

  1. Оберіть шаблон делегата Define business process status у списку доступних.

  2. У полі Status введіть статус — Самореєстрацію пройдено.

officer self register manual mod 15

3.16. Відправлення рішення назад до процесу заявника реєстрації

Ця задача є завершальною подією (Message End Event) у процесі підтвердження самореєстрації модератором. Вона виконує наступні функції:

  1. Встановлює зв’язок з процесом реєстранта через параметр correlationProcessInstanceId, що отримує значення з ID процесу-викликача (${process_caller().id}).

  2. Передає дані про рішення відносно самореєстрації через параметр messageData. Цей параметр містить відомості про позитивне чи негативне рішення (${submission('signDecisionActivity').formData.prop('selfregistrationDecision').value()}).

  3. Використовує делегат ${sendMessageDelegate} для відправки повідомлення з вищезазначеними даними.

Детальніше про Message End Event ви можете переглянути на сторінці Моделювання та налаштування кінцевої події повідомлення.
Виконайте наступні налаштування:

  1. У розділі Implementation вкажіть:

    • Тип — Delegate expression.

    • Вираз — ${sendMessageDelegate}. Змінна є імплементацією делегата.

  2. У розділі Global message reference:

    • Оберіть decisionMessage зі списку доступних.

    • У полі Name продублюйте значення decisionMessage для зручності.

  3. У розділі Inputs вкажіть вхідні дані для передачі до іншого процесу:

    • Створіть локальну змінну correlationProcessInstanceId.

      • Визначте для неї тип String or Expression, тобто рядок або вираз.

      • У полі Value передайте ідентифікатор процесу, який викликав поточний процес. Зробити це можна наступним чином за допомогою функції process_caller():

        ${process_caller().id}

    • Створіть локальну змінну messageData.

      • Визначте для неї тип Map, тобто ключі-значення.

      • Передайте набір ключів-значень як Map entries у полях Key та Value. Зробити це можна наступним чином за допомогою функції submission():

        • Key: isDecisionPositive (вказує на ключ до позитивного результату, який підтверджує реєстрацію посадової особи)

        • Value: ${submission('signDecisionActivity').formData.prop('selfregistrationDecision').value()}

officer self register manual mod 16

officer self register manual mod 16 1

3.17. Отримання повідомлення про те, що рішення про автореєстрацію прийнято та записано до Фабрики даних

Ця подія є проміжною подією отримання повідомлення (Intermediate Message Catch Event) у процесі BPMN. Вона служить для очікування та перехоплення вхідного повідомлення, яке відправлено іншим процесом або учасником. Зазвичай такі події використовуються для синхронізації або координації між різними процесами чи учасниками у бізнес-процесі.

Детальніше про Intermediate Message Catch Event ви можете переглянути на сторінці Моделювання та налаштування проміжної події отримання повідомлення.
Виконайте налаштування події наступним чином:

У розділі Global message reference:

  1. Оберіть decisionMessage зі списку доступних.

  2. У полі Name продублюйте значення decisionMessage для зручності.

officer self register manual mod 17

3.18. Моделювання XOR-шлюзу та додавання логіки через вирази умови

Змоделюйте XOR-шлюз, який на основі певної умови визначатиме, за яким потоком далі піде бізнес-процес.

officer self register manual mod 18

Якщо рішення про реєстрацію негативне і передається повідомленням від процесу модератора як ключ ${!isDecisionPositive}, тоді процес піде за альтернативним потоком, а користувач не пройде реєстрацію. Роль такого користувача не зміниться й залишиться unregistered-officer.

officer self register manual mod 18 1

Якщо рішення про реєстрацію позитивне і передається повідомленням від процесу модератора як ключ ${isDecisionPositive}, тоді процес піде за основним потоком, а користувач пройде реєстрацію. Роль такого користувача зміниться у наступній сервісній задачі з unregistered-officer на officer.

officer self register manual mod 18 2

3.19. Виведення інформації на форму про відсутність дозволу на реєстрацію (альтернативний потік)

Ця задача є користувацькою задачею (User Task) і призначена для надання інформації користувачеві про відсутність дозволу на реєстрацію.

Ця задача призначена для ініціатора процесу (camunda:assignee="${initiator}"), який є заявником. Форма, пов’язана з цією задачею, має ключ selfregistration-denied-handmoderation (camunda:formKey="selfregistration-denied-handmoderation"), який відображає форму з інформацією про відсутність дозволу на реєстрацію.

Виконайте налаштування наступним чином:

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

  2. Застосуйте шаблон делегата для цієї задачі — User Form.

  3. Поєднайте користувацьку задачу із UI-формою за допомогою параметра Form key. Введіть значення selfregistration-denied-handmoderation.

  4. У полі Assignee вкажіть змінну для особи, якій призначається поточна задача, — ${initiator}.

officer self register manual mod 19

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

3.20. Видалення ролі unregistered-officer та призначення ролі officer посадовій особі

Після підтвердження реєстрації, дані передаються до сервісної задачі, яка використовує делегат Save user roles для перепризначення ролей користувачам та збереження їх до БД Keycloak.

Ця задача виконує наступні дії:

  1. Видаляє роль unregistered-officer у користувача, який проходить самореєстрацію.

  2. Додає роль officer до користувача після успішної самореєстрації.

Задача використовує делегат ${keycloakSaveUserRoleConnectorDelegate}, який взаємодіє з Keycloak для зміни ролей користувача. Інформація про ролі та інші параметри передаються через input-параметри:

  • realm встановлюється як OFFICER.

  • roles містить список ролей, які будуть додані користувачу (у цьому випадку — officer).

  • username отримує значення імені користувача, який проходить самореєстрацію (${initiator().userName}).

  • roleType встановлюється на ALL ROLES, що вказує на те, що зміни будуть застосовані до всіх ролей користувача.

delegate save user roles 1

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

3.21. Виведення на форму інформації по успішне завершення процесу реєстрації

Ця задача (User Task) відображає інформаційне повідомлення для користувача після успішної самореєстрації. Користувач повинен переглянути інформацію та підтвердити її перегляд. Задача використовує шаблон форми User form та ключ форми selfregistration-success для відображення відповідного інтерфейсу користувача. Задача призначена для виконання ініціатором процесу самореєстрації (${initiator}).

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

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

  2. Застосуйте шаблон делегата для цієї задачі — User Form.

  3. Поєднайте користувацьку задачу із UI-формою за допомогою параметра Form key. Введіть значення selfregistration-success.

  4. У полі Assignee вкажіть змінну для особи, якій призначається поточна задача, — ${initiator}.

officer self register manual mod 20

3.22. Встановлення результату виконання та завершення процесу

У наступних задачах встановіть результат виконання процесу, використавши для цього сервісну задачу та делегат Define business process status, та закінчіть процес подією завершення (End event).