Створення задач від надавача послуг громадянину в рамках бізнес-процесу, ініційованого громадянином: референтний приклад

На цій сторінці:

1. Загальний опис референтного бізнес-процесу

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

Основні компоненти:

  1. Подача заяви:
    Отримувач послуг подає заяву на отримання ліцензії, використовуючи типове розширення для формування бізнес-ключа (наприклад, код ЄДРПОУ).

  2. Обробка заяви:
    Заява обробляється посадовою особою через серію задач, включаючи користувацьку задачу з формою заповнення, підписання задачі та скриптову задачу для збору даних.

  3. Взаємодія з Кабінетами:
    Моделювання включає два пули для користувачів різних Кабінетів, забезпечуючи взаємодію між ними.

  4. Коригування та повторна подача заяви:
    За потреби доопрацювати заяву, заявник вносить відповідні правки та повторно подає заяву.

  5. Завершення процесу:
    Процес завершується або з погодженням видачі ліцензії, або з поверненням заяви на доопрацювання, залежно від рішення надавача послуг.

Переваги:

  • Покращення досвіду моделювання завдяки використанню раніше реалізованих елементів.

  • Ефективна взаємодія між користувачами різних кабінетів.

  • Гнучкість у коригуванні та повторній подачі заяв, забезпечуючи прозорість та ефективність обробки.

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

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

2.1. Референтні приклади бізнес-процесу та UI-форм

Де можна знайти приклад референтного бізнес-процесу?

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

Еталонний регламент з прикладами для України зберігається в репозиторії ua-registry-demo-regulation.

Детальну інструкцію щодо розгортання демо-реєстру та отримання референтних прикладів моделювання ви знайдете на сторінці Розгортання демо-реєстру із референтними прикладами.

Приклад BPMN-схеми процесу буде доступний у регламенті демо-реєстру за пошуком по ключовим словам — reference-license-application-with-back-for-update. Назви форм ви можете знайти всередині відповідних користувацьких задач (User Task) бізнес-процесу у полі Form key:

  • form-license-application-store-fuel.json

  • sign-form-license-application-store-fuel-2.json

  • view-license-application-officer.json

  • application-status-officer.json

  • sign-application-status-officer.json

  • view-notes-result-citizen.json

bp submit application cit off 1
Зображення 1. Загальний вигляд референтного процесу у Кабінеті адміністратора регламентів. Пул отримувача послуг
bp submit application cit off 2
Зображення 2. Загальний вигляд референтного процесу у Кабінеті адміністратора регламентів. Пул надавача послуг

2.2. Референтні приклади структури даних

Логічна модель даних

Змоделюйте Liquibase changeset для створення таблиці license_application відповідно до вашої логічної моделі даних. У нашому референтному прикладі використано наступну логічну модель:

ERD-діаграма референтної логічної моделі
Зображення 3. ERD-діаграма референтної логічної моделі

Фізична модель даних

На базі поданої логічної моделі, створіть фізичну модель даних. У нашому прикладі використано ChangeSet 28535-3 із регламенту демо-реєстру. Модель буде доступна за шляхом: data-model/createTables.xml.

Референтна фізична модель. Створення таблиці licence_application 
<changeSet id="28535-3" author="kk">
    <createTable tableName="licence_application" ext:historyFlag="true">
        <column name="id" type="UUID" defaultValueComputed="uuid_generate_v4()">
            <constraints nullable="false" primaryKey="true" primaryKeyName="license_application_id"/>
        </column>
        <column name="full_name" type="TEXT">
            <constraints nullable="false"/>
        </column>
        <column name="edrpou" type="TEXT">
            <constraints nullable="false"/>
        </column>
        <column name="applicant_address" type="TEXT">
            <constraints nullable="false"/>
        </column>
        <column name="applicant_phone" type="TEXT">
            <constraints nullable="false"/>
        </column>
        <column name="application_name" type="application_name_type">
            <constraints nullable="false"/>
        </column>
        <column name="application_date" type="DATE" remarks="Дата заяви">
            <constraints nullable="false"/>
        </column>
        <column name="application_status" type="application_status_type">
            <constraints nullable="false"/>
        </column>
    </createTable>
</changeSet>
Пояснення до структури:

Ця структура використовується для створення таблиці licence_application з різними полями, включаючи ідентифікатор, ім’я, адресу та інші важливі атрибути заявки на ліцензію, з відповідними обмеженнями для кожної колонки.

Тег Опис

<changeSet>

Цей тег визначає набір змін у базі даних. Кожен changeSet має унікальний ідентифікатор (id) та автора (author), що дозволяє системі відстежувати, які зміни були застосовані та ким.

<createTable>

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

<column>

Кожен такий тег визначає колонку в таблиці. Наприклад, name="id" визначає колонку з ім’ям id.

type

Цей атрибут визначає тип даних для колонки, наприклад, UUID або TEXT.

defaultValueComputed

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

<constraints>

Цей тег визначає обмеження для колонок. Наприклад, nullable="false" вказує, що колонка не може містити null-значення. primaryKey="true" означає, що колонка є первинним ключем.

remarks

Це примітка до колонки, яка може містити додаткову інформацію. У нашому випадку для application_date примітка - "Дата заяви".
Детальну інформацію про створення таблиць та інші теги ви можете переглянути на сторінці Розширення Liquibase для моделювання даних.

Приклад SQL-коду

На базі створеної фізичної моделі, Liquibase формує SQL-код. У нашому випадку сформований SQL-запит може виглядати наступним чином:

CREATE TABLE licence_application (
    id UUID NOT NULL DEFAULT uuid_generate_v4(),
    full_name TEXT NOT NULL,
    edrpou TEXT NOT NULL,
    applicant_address TEXT NOT NULL,
    applicant_phone TEXT NOT NULL,
    application_name application_name_type NOT NULL,
    application_date DATE NOT NULL,
    application_status application_status_type NOT NULL,
    PRIMARY KEY (id)
);

-- Additional comments
COMMENT ON COLUMN licence_application.application_date IS 'Дата заяви';
Пояснення до запита:
Стовпець Тип Обмеження Додаткові пояснення

id

UUID

NOT NULL, PRIMARY KEY, DEFAULT uuid_generate_v4()

Унікальний ідентифікатор для кожного запису. Значення генерується автоматично.

full_name

TEXT

NOT NULL

Повне ім’я заявника.

edrpou

TEXT

NOT NULL

Код ЄДРПОУ заявника.

applicant_address

TEXT

NOT NULL

Адреса заявника.

applicant_phone

TEXT

NOT NULL

Телефонний номер заявника.

application_name

application_name_type

NOT NULL

Назва заявки. Повинен бути визначений як ENUM у базі даних.

application_date

DATE

NOT NULL

Дата подання заявки. 'Дата заяви' — коментар до стовпця.

application_status

application_status_type

NOT NULL

Статус заявки. Повинен бути визначений як ENUM у базі даних.

3. Опис бізнес-процесу

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

3.1. Моделювання пулів для учасників бізнес-процесу (Надавач та отримувач послуг)

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

Загальний бізнес-процес ініціює отримувач послуг.

3.2. Формування бізнес ключа (отримувач послуг)

Створіть сервісну задачу та застосуйте шаблон делегата для формування бізнес-ключа — Define process business key. У цьому прикладі використано значення коду ЄДРПОУ заявника.

Бізнес-ключ
${initiator().edrpou}
bp submit application cit off 3

3.3. Заповнення даних заяви на отримання ліцензії

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

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

  2. У полі ID вкажіть ідентифікатор задачі. Наприклад, UserTask_FillCertificateRequestData.

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

  4. Form key: reference-form-license-application-store-fuel. Вказує на службову назву UI-форми у бізнес-процесі.

  5. Assignee: ${initiator}.

bp submit application cit off 4

3.4. Підписання даних у заяві

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

  1. У полі ID вкажіть ідентифікатор задачі. Наприклад, UserTask_SignCertificateRequestData.

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

  3. Form key: reference-sign-form-license-application-store-fuel-2. Вказує на службову назву UI-форми у бізнес-процесі.

  4. Assignee: ${initiator}.

  5. Form data pre-population: ${submission('UserTask_FillCertificateRequestData').formData}. Використовуйте дані попередньої UI-форми для автоматичного заповнення поточної. Наприклад, ${formData}. У нашому випадку використано кастомну JUEL-функцію submission() та метод formData для отримання даних із відповідної форми 'UserTask_FillCertificateRequestData'.

  6. Вкажіть тип отримувача послуг та статус активації. Це може бути фізична особа (INDIVIDUAL), фізична особа-підприємець (ENTREPRENEUR) або юридична особа (LEGAL):

    • INDIVIDUAL: enable

    • ENTREPRENEUR: enable

    • LEGAL: enable

    INDIVIDUAL, ENTREPRENEUR та LEGAL є регламентними ролями, які призначаються отримувачу послуг за результатом проходження самостійної реєстрації в системі.
bp submit application cit off 5

3.5. Скрипт: підготовка даних для процесу валідації

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

bp submit application cit off 6
Groovy-скрипт
def submissionData = submission('UserTask_SignApplicationData').formData
println("revert point : submissionData = "+submissionData)

def formDataForm = submissionData==null?submission('UserTask_SignCertificateRequestData').formData:submissionData
println("revert point : formDataForm = "+formDataForm)

def data = [:]

	data['fullName'] = formDataForm.prop('fullName').value();
	data['edrpou'] = formDataForm.prop('edrpou').value();
	data['address'] = formDataForm.prop('address').value();
	data['phone'] = formDataForm.prop('phone').value();
	data['requestType'] = formDataForm.prop('requestType').value();
	data['requestDate'] = formDataForm.prop('requestDate').value();
	data['confirmDocAccuracy'] = formDataForm.prop('confirmDocAccuracy').value();

def payload = S(data, 'application/json')
set_transient_variable('payload', payload)

Цей скрипт призначений для збору даних форми та підготовки їх у форматі JSON для подальшої обробки у бізнес-процесі. Він використовує мову програмування Groovy.

Розглянемо більш детально, що робить цей скрипт:

  1. Витягує дані із попередньої форми:

    def submissionData = submission('UserTask_SignApplicationData').formData
println("revert point : submissionData = "+submissionData)

    Скрипт витягує дані з форми UserTask_SignApplicationData. Ці дані витягуються як formData і виводяться в консоль для відстеження.

  2. Визначає дані для подальшої роботи:

    def formDataForm = submissionData==null?submission('UserTask_SignCertificateRequestData').formData:submissionData
println("revert point : formDataForm = "+formDataForm)

    Якщо submissionData є null, скрипт витягує дані з форми UserTask_SignCertificateRequestData, інакше використовує вже отримані submissionData. Це гарантує, що у скрипту завжди є дані для обробки.

  3. Ініціалізує об’єкт для збору даних:

    def data = [:]

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

  4. Збирає дані з форми:

    data['fullName'] = formDataForm.prop('fullName').value();
data['edrpou'] = formDataForm.prop('edrpou').value();
data['address'] = formDataForm.prop('address').value();
data['phone'] = formDataForm.prop('phone').value();
data['requestType'] = formDataForm.prop('requestType').value();
data['requestDate'] = formDataForm.prop('requestDate').value();
data['confirmDocAccuracy'] = formDataForm.prop('confirmDocAccuracy').value();

    У цій частині скрипт збирає всі необхідні дані з formDataForm, витягуючи значення властивостей, таких як fullName, edrpou та інші, та зберігає їх у словнику data.

  5. Перетворює зібрані дані у формат JSON та зберігає їх для подальшого використання:

    def payload = S(data, 'application/json')
set_transient_variable('payload', payload)

    Дані зі словника data перетворюються у JSON-рядок. Цей JSON-рядок (payload) потім зберігається як тимчасова змінна payload для використання у подальших частинах бізнес-процесу.

3.6. Відправлення заяви для перевірки

Далі створіть подію Message Intermediate Throw Event для відправлення даних щодо заяви до підпроцесу для опрацювання посадовою особою. Заповніть наступні поля:

  1. ID: вкажіть ідентифікатор задачі, наприклад, throwMessageToOrricerProcess.

  2. Implementation:

    1. Type: Delegate expression

    2. Delegate expression: ${startProcessByMessageDelegate}

  3. Message:

    1. Global message reference: Message_officer_validation

    2. Name: Message_officer_validation

  4. Inputs > messagePayload:

    1. Local variable name: messagePayload

    2. Assignment type: Map

    3. Map entries: Ключі address, businessKey, confirmDocAccuracy, edrpou, fullName, phone, requestDate, requestType, userName.

      Передайте значення відповідних атрибутів наступним чином:

      Приклад виразу для параметра address
      ${payload.value.prop('address').value()}
bp submit application cit off 7
Зображення 4. Налаштування Message Intermediate Throw Event
bp submit application cit off 7 1
Зображення 5. Message Intermediate Throw Event. Деталі Input > Map entries

3.7. Отримання заяви для перевірки

Далі у нижньому пулі для надавача послуг додайте Message Start Event.

  1. ID: startCertificateMessageEvent.

  2. Message (має збігатися з налаштуваннями Message Intermediate Throw Event):

    1. Global message reference: Message_officer_validation

    2. Name: Message_officer_validation

  3. Start initiator > Initiator: citizen

bp submit application cit off 8

3.8. Скрипт: підготовка даних для форми

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

bp submit application cit off 9
Groovy-скрипт
set_transient_variable('payload', S(message_payload('startCertificateMessageEvent').data, 'application/json'))

Скрипт призначений для встановлення тимчасової змінної з даними, отриманими від повідомлення, та перетворення цих даних у формат JSON. Розглянемо більш детально:

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

  1. Отримує дані від повідомлення: message_payload('startCertificateMessageEvent').data отримує дані (data) з повідомлення, що було прийнято подією startCertificateMessageEvent.

  2. Перетворює дані у формат JSON та зберігає у тимчасовій змінній: S(…​, 'application/json') виконує серіалізацію отриманих даних у формат JSON. Ця серіалізований JSON-рядок потім зберігається як тимчасова змінна під назвою payload в контексті поточного бізнес-процесу або робочого потоку.

3.9. Формування бізнес ключа (надавач послуг)

Створіть сервісну задачу та застосуйте шаблон делегата для формування бізнес-ключа — Define process business key. У цьому прикладі використано значення коду ЄДРПОУ заявника. Бізнес-ключ формується із вказаних заявником даних у полі ЄДРПОУ при заповненні форми заяви.

Бізнес-ключ
${payload.value.prop('businessKey').value()}
bp submit application cit off 10

3.10. Перегляд заяви посадовою особою

Далі додайте користувацьку задачу з формою reference-view-license-application-officer для перегляду заяви посадовою особою.

  1. ID: UserTask_CheckRequestByOfficer.

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

  3. Candidate roles: op-reference.

  4. Form data pre-population: ${payload}. Використовуйте дані, сформовані скриптом для автоматичного заповнення поточної UI-форми. Наприклад, ${formData}.

  5. Form variables: officerUsers. Вкажіть змінні UI-форми, які будуть оброблені формою.

bp submit application cit off 11

3.11. Ухвалення рішення щодо заяви

Змоделюйте наступну користувацьку задачу. При моделюванні задачі та UI-форми для неї (reference-application-status-officer), під компонентом Radio Button додано текстове поле, яке буде показано лише за умови обраного рішення про повернення заяви на доопрацювання.

  1. ID: UserTask_AddStatus

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

  3. Assignee: ${completer('UserTask_CheckRequestByOfficer').userName}

bp submit application cit off 12
Зображення 6. Користувацька задача при моделюванні бізнес-процесу
bp submit application cit off 13
Зображення 7. Моделювання UI-форми до задачі. Вкладка "Перегляд"

Для налаштування такої умови моделювальник переходить у режим налаштувань компонента Text Field і на вкладці Conditional додає відповідну умову у розділі Simple.

bp submit application cit off 14
Зображення 8. Компонент Text Field. Моделювання умови

Після цього у підпроцесі додайте форму підписання даних КЕП, системний підпис та сервісну задачу з типовим розширенням для збереження ухваленого рішення в базу даних реєстру.

bp submit application cit off 15

3.12. Підписання даних КЕП отримувача послуг

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

  1. У полі ID вкажіть ідентифікатор задачі. Наприклад, UserTask_SignSuccessfulStatusActivity.

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

  3. Form key: reference-sign-application-status-officer. Вказує на службову назву UI-форми у бізнес-процесі.

  4. Assignee: ${completer('UserTask_AddStatus').userName}.

  5. Form data pre-population: ${submission('UserTask_AddStatus').formData}. Використовуйте дані попередньої UI-форми для автоматичного заповнення поточної. Наприклад, ${formData}. У нашому випадку використано кастомну JUEL-функцію submission() та метод formData для отримання даних із відповідної форми 'UserTask_AddStatus'.

bp submit application cit off 15 1

3.13. Скрипт: підготовка даних для запису (transient var)

Додайте скрипт, який підготує дані до запису у БД.

bp submit application cit off 15 2
Groovy-скрипт
def formStatusData = submission('UserTask_SignSuccessfulStatusActivity').formData

def formCheckData = submission('UserTask_CheckRequestByOfficer').formData

def data = [:]
	data['fullName'] = formCheckData.prop('fullName').value();
	data['edrpou'] = formCheckData.prop('edrpou').value();
	data['applicantAddress'] = formCheckData.prop('address').value();
	data['applicantPhone'] = formCheckData.prop('phone').value();

	if(formCheckData.prop('requestType').value().equals('getLicense')){
	    data['applicationName'] = 'GET_LICENSE';
	}else{
		data['applicationName'] = 'TERMINATE_LICENSE';
	}

	data['applicationDate'] = formCheckData.prop('requestDate').value();

	if(formStatusData.prop('approveStatus').value().equals('approveLicense'))
	{
		data['applicationStatus'] = 'APPROVED';
	}else{
		data['applicationStatus'] = 'RETURNED_FOR_REVISION';
	}

def payload = S(data, 'application/json')
set_transient_variable('payload', payload)

Цей скрипт призначений для збору та обробки даних з форм/ Основна мета — створити й зберегти об’єкт JSON з даними, які потім можуть використовуватися у бізнес-процесах.

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

  1. Витягує дані з попередніх форм:

    def formStatusData = submission('UserTask_SignSuccessfulStatusActivity').formData
def formCheckData = submission('UserTask_CheckRequestByOfficer').formData

    Скрипт використовує JUEL-функцю submission для витягу даних форми з двох різних задач: UserTask_SignSuccessfulStatusActivity та UserTask_CheckRequestByOfficer. Ці дані зберігаються у змінних formStatusData та formCheckData відповідно.

  2. Ініціалізує об’єкт для збору даних:

    def data = [:]

    Створює порожній словник (data), в який будуть збиратися необхідні дані.

  3. Збирає дані з форми formCheckData:

    data['fullName'] = formCheckData.prop('fullName').value();
data['edrpou'] = formCheckData.prop('edrpou').value();
data['applicantAddress'] = formCheckData.prop('address').value();
data['applicantPhone'] = formCheckData.prop('phone').value();

    Дані, такі як повне ім’я, код ЄДРПОУ, адреса та телефон заявника, збираються з форми і додаються до словника data.

  4. Визначає тип заявки залежно від значення requestType:

    if(formCheckData.prop('requestType').value().equals('getLicense')){
    data['applicationName'] = 'GET_LICENSE';
}else{
	data['applicationName'] = 'TERMINATE_LICENSE';
}

    Значення applicationName визначається на основі типу заявки (getLicense або інше).

  5. Додає дату заявки до словника data:

    data['applicationDate'] = formCheckData.prop('requestDate').value();

    Дата заявки збирається з форми й додається до словника.

  6. Визначає статус заявки на основі formStatusData:

    if(formStatusData.prop('approveStatus').value().equals('approveLicense'))
{
	data['applicationStatus'] = 'APPROVED';
}else{
	data['applicationStatus'] = 'RETURNED_FOR_REVISION';
}

    Статус заявки ('APPROVED' або 'RETURNED_FOR_REVISION') визначається на основі відповіді у формі статусу.

  7. Перетворює зібрані дані у формат JSON та зберігає їх у тимчасовій змінній:

    def payload = S(data, 'application/json')
set_transient_variable('payload', payload)

    Зібрані дані перетворюються у формат JSON і зберігаються у тимчасовій змінній payload, яка може використовуватися в інших частинах бізнес-процесу.

3.14. Підпис даних системним цифровим ключем (цифрова печатка)

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

  1. Застосуйте шаблон делегата System signature by DSO service.

  2. ID: signDataWithSystemKey.

  3. Template: signDataWithSystemKey.

  4. Payload: ${payload}.

  5. X-Access-Token source: ${completer('UserTask_SignSuccessfulStatusActivity').accessToken}.

  6. Result variable: system_signature_ceph_key.

Більш детально з налаштуваннями делегата підпису читайте на сторінці Делегат для підпису даних системним ключем (System signature by DSO service).
bp submit application cit off 15 3

3.15. Збереження даних до БД

Збережіть дані до постійного сховища. Для створення сервісної задачі, що зберігатиме дані до БД, виконайте наступні кроки:

  1. Створення задачі:

    • Додайте нову сервісну задачу (Service Task) у вашому бізнес-процесі. Ця задача буде відповідати за збереження оброблених та підписаних даних.

  2. Налаштування параметрів задачі:

    1. У полі Name вкажіть назву задачі, яка відображатиме її функцію, наприклад, Збереження оброблених даних.

    2. Застосуйте шаблон делегата Create entity in data factory.

    3. Вкажіть ID задачі. Наприклад, saveDataToFactory.

    4. У полі Resource вкажіть ресурс або назву API-ендпоінту, через який будуть зберігатися дані. У нашому випадку — licence-application.

    5. У полі Payload вкажіть тіло запита: ${payload}. Це передає дані, які необхідно зберегти, і які були підготовлені на попередніх етапах.

    6. У полі X-Access-Token вкажіть ${completer('UserTask_SignSuccessfulStatusActivity').accessToken}. Це токен доступу користувача, що забезпечує авторизацію для здійснення операції збереження.

    7. У полі X-Digital-Signature source вкажіть ${sign_submission('UserTask_SignSuccessfulStatusActivity').signatureDocumentId}. Це ідентифікатор документа, який містить цифровий підпис.

    8. У полі X-Digital-Signature-Derived source вкажіть ${system_signature_ceph_key}. Це посилання на ключ цифрового підпису, отриманого від системи.

    9. У полі Result variable вкажіть назву для вихідного параметра, наприклад, response. Це буде змінна, в якій зберігатиметься результат операції збереження.

bp submit application cit off 15 4

3.16. Використання XOR-шлюзу для розгалуження бізнес-процесу

XOR-шлюз використовується для визначення розгалуження процесу на основі умов. Після встановлення XOR-шлюзу, необхідно додати сервісну задачу з типовим розширенням Define business process status, яка буде відповідати прийнятому рішенню.

  • Варіант "Так": Якщо ухвалено позитивне рішення ("Ліцензію погоджено"), то умова переходу (Condition Expression) на стрілці шлюзу буде наступною:

    ${submission('UserTask_AddStatus').formData.prop("approveStatus").value().equals('approveLicense')}

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

    bp submit application cit off 16

  • Варіант "Ні": Якщо ухвалено негативне рішення ("Повернення на доопрацювання"), то умова переходу (Condition Expression) на стрілці шлюзу буде такою:

    ${submission('UserTask_AddStatus').formData.prop("approveStatus").value().equals('returnForRevision')}

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

    bp submit application cit off 16 1

3.17. Відправлення нотифікацій заявнику

bp submit application cit off 17

Підготуйте скрипт для кожного потоку процесу.

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

Для потоку з доопрацюванням скрипт може виглядати так: 
def appName = payload.prop('applicationName').value();

var templateModel = [
  'applicationName': appName
]

set_transient_variable('templateModel', S(templateModel, 'application/json'))

def businessKey = execution.getProcessBusinessKey();

  1. Отримує назву заявки з payload:

    def appName = payload.prop('applicationName').value();

    Скрипт витягує назву заявки (applicationName) з об’єкта payload, який містить дані заявки.

  2. Створює модель даних для шаблону:

    var templateModel = [
  'applicationName': appName
]

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

  3. Зберігає модель даних як тимчасову змінну у форматі JSON:

    set_transient_variable('templateModel', S(templateModel, 'application/json'))

    Модель templateModel перетворюється в формат JSON і зберігається як тимчасова змінна templateModel.

  4. Отримує бізнес-ключ процесу:

    def businessKey = execution.getProcessBusinessKey();

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

Для потоку з погодженням заявки скрипт може виглядати так: 
def appName = payload.prop('applicationName').value();

var templateModel = [
  'applicationName': appName
]

set_transient_variable('templateModel', S(templateModel, 'application/json'))

  1. Отримує назву заявки з payload та створює модель даних для шаблону:

    def appName = payload.prop('applicationName').value();
var templateModel = [
  'applicationName': appName
]
set_transient_variable('templateModel', S(templateModel, 'application/json'))

    Ця частина скрипту аналогічна до скрипту для потоку з доопрацюванням: вона отримує назву заявки з payload, створює модель даних templateModel, перетворює її в JSON та зберігає як тимчасову змінну. Головна відмінність полягає у відсутності кроку з отриманням бізнес-ключа, що може бути пов’язано з логікою конкретного потоку процесу.

Далі змоделюйте відправлення повідомлень користувачу.

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

3.18. Подієвий шлюз (Event-based gateway) та подія "Повідомлення" для отримання позитивного результату

  1. У батьківському процесі додайте шлюз Event-based gateway, який направляє токен до завершення процесу отримання ліцензії для заявника у тому випадку, коли надавачем послуг ухвалено рішення про погодження видачі ліцензії.

  2. Далі змоделюйте Message Intermediate Catch Event для перехоплення вхідних повідомлень між процесами:

    1. ID: gotSuccessfulResponse

    2. Message > Global message reference: SuccessfullCompletionMessage

    3. Message > Name: SuccessfullCompletionMessage

bp submit application cit off 18

3.19. Повернення на доопрацювання для виправлення помилок у заяві

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

  1. Змоделюйте Message Intermediate Catch Event для перехоплення вхідних повідомлень між процесами.

  2. ID: gotRejectedResponse.

  3. Message > Global message reference: NeedUserUpdateMessage.

  4. Message > Name: NeedUserUpdateMessage.

Далі внесіть скрипт для підготування даних до показу. Він може виглядати так:

def data = [:]
data.notates = notates
data.address = address
data.confirmDocAccuracy = confirmDocAccuracy
data.edrpou = edrpou
data.fullName = fullName
data.phone = phone
data.requestDate = requestDate
data.requestType = requestType
data.businessKey = businessKey


set_transient_variable('payload', S(data, 'application/json'))
//set_transient_variable('payload', S(message_payload('startCertificateMessageEvent').data, 'application/json'))
bp submit application cit off 19

Далі сформуйте бізнес-ключ, як показано у попередніх кроках процесу.

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

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