Технічне завдання: Редактор BP-моделей K2 ERP
23.1.; Загальна структура YAML
=== 36.6.; Симуляція ===
* створювати бізнес-процеси у графічному вигляді;
* описувати етапи, задачі, події, переходи, умови та виконавців;
* задавати правила погодження документів;
* описувати автоматичні дії системи;
* налаштовувати інтеграційні кроки;
* зберігати модель процесу у YAML;
* версіонувати бізнес-процеси;
* перевіряти бізнес-процес на логічні помилки;
* генерувати виконувані workflow-схеми;
* формувати документацію по процесу;
* використовувати BP-модель як єдине джерело правди для виконання бізнес-процесу.; компонент; додатково реалізовано маршрутизації документів.; |-
|action
|Тип дії.; користувач системи має змогу створити перехід між вузлами.; 5.; Transitions з умовами.; {| class="wikitable"
!характеристика
=== 12.3.; Дії користувача в User Task ===
=== 31.1.; Що логувати ===
document.status == "draft"
document.currency == "UAH" and document.amount <= 50000
user.has_role("finance_manager")
approval.result == "rejected"
!Поле
- id: end_rejected
17.1.; Призначення
actions:
+--------------------------------------------------------------------------------+
35.1.; Що включити в MVP
Редактор має мати простий механізм для задання умов.; Складне merge-версій.; |- |label |string |Так |Людинозрозуміла назва.; Архітектор затверджує бізнес-процес.; |- |webhook |Webhook у зовнішню систему.; |- |object_type |Process, Node, Transition, Variable, Version.; Повний visual debugger runtime-процесу.; |- |label |string |Назва вузла на діаграмі.; |- |Бізнес-процес |Послідовність дій, рішень, подій і автоматичних операцій.; |- |form |reference |Ні |Форма, яку потрібно показати.; |- |entity |string |Сутність або документ, який запускає бізнес-процес.; |Підключення handler-ів, scripts, API.; |}
document.currency == "UAH" user.role == "finance_manager"Тип
34.1.; Продуктивністьfrom: manager_approval Process runtime | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Start Event | start | class="wikitable"
type: system_task - id: t_finance_approved |-
|string
|Рядок.; Валідація процесу.; |-
|send_notification
|Надіслати повідомлення.; - id: start
5.; 3.; |}
!Поле
=== 21.2.; Приклад SLA ===
purchase_approval.bpmn
4.; |-
|started_by
|reference
|Хто запустив бізнес-процес.; |}
== 37.; Приклад сценарію роботи користувача ==
== 31. Audit log ==
Симулятор потрібен, щоб перевірити логіку процесу без запуску реальних документів.;== 23.; YAML-формат BP-моделі ==
!характеристика
</syntaxhighlight>
↓
10.; |-
|require_comment_on_reject
|boolean
|Чи обовʼязковий коментар при відхиленні.; Створення BP-моделі.; |-
|type
|string
|start.;<pre>
|-
|method
|enum
|GET, POST, PUT, PATCH, DELETE.; |-
|boolean
|Логічне значення.; |-
|name
|string
|Так
|Технічна назва задачі.; 5.; |-
|PUT
|/api/bp-models/{id}
|Оновити BP-модель.; 3.; |-
|System Task
|system_task
|Автоматична дія системи.; BPMN import у повному обсязі.; платформа має:
1.; |-
|label
|string
|Так
|Назва для користувача.; 5.; Реалізувати YAML import.; користувач системи має змогу створити нову BP-модель.; sla:
!Режим
result: rejected
type: string
process:
=== 36.7.; Публікація ===
finance action = approve
3.; |-
|model_version_id
|uuid
|реліз моделі.; Якщо сума понад 100 000 грн — додається погодження фінансиста.; |}
{| class="wikitable"
!характеристика
document.amount = 150000
{| class="wikitable"
purchase_approval.yml
5.; |-
|користувач системи ERP
|Виконує задачі в рамках процесу.; |Щодня о 09:00.;== 9.; Типи вузлів процесу ==
name: FinanceApproval
!Генератор
=== 20.1.; Вимоги ===
3.; |-
|status
|enum
|running, completed, cancelled, failed, suspended.; |-
|Delete
|Видалити вибраний вузол або перехід після підтвердження.; |-
|Інтеграційний крок не відповідає
|бізнес-процес зупиняється.; |-
|required_fields
|list
|Ні
|Поля, які потрібно заповнити.; 1.; +--------------------------------------------------------------------------------+
2.; |}
source: document.currency
3.; |Ні.; 2.; |-
|Transition / Перехід
|Звʼязок між вузлами процесу.; Генерація документації.;=== 27.2.; Генератори ===
3.; |-
|Старі екземпляри
|Вже запущені процеси продовжують виконуватися на старій версії.; action: approve
reminder_before: 4h
!характеристика
{| class="wikitable"
generators:
|-
|id
|uuid
|ID екземпляра процесу.; Реалізувати панель властивостей.; платформа показує фінальний end node.; Реалізувати умови переходів.; |-
|from
|string
|Так
|Початковий вузол.; options:
11.; Створити runtime-сутності.; |}
- id: t_rejected_end
!Тип
K2 Workflow Engine
|-
| style="background:#d4edda; color:#155724; font-weight:bold;" |Рекомендовано
|Використовувати зареєстровані handler-и, а не довільний код у YAML.; користувач системи має змогу додати End Event.; |-
|Клік по переходу
|Відкрити умови переходу.;== 14. System Task ==
to: change_status_approved
!Правило
name: ChangeStatusRejected
Approval Task застосовують, коли потрібно для погодження документів, заявок, платежів, договорів або інших обʼєктів K2 ERP.;<pre>
=== Етап 1.; 39.1.; аналітичні інструменти ===
type: system_task
!характеристика
!характеристика
↓
document.amount > 100000
6.; |-
|Gateway
|Умова або розгалуження процесу.; |-
|action
|string
|Яку дію обрав користувач системи.; |-
|input
|object
|Вхідні параметри.; |-
|Diagram-first
|користувач системи редагує графічну діаграму, YAML оновлюється автономно.; Помилки YAML показуються користувачу.; Live collaboration.; |-
| style="background:#f8d7da; color:#721c24; font-weight:bold;" |Заборонено
|Дозволяти виконання довільного Python/SQL/JS у звичайних умовах.; transitions: []
!Код
due_in: 2d
label: Завершено: відхилено
=== 11.3.; Властивості Start Event ===
!Основні дії
create_stub_handlers: true
!характеристика
!Рівень
Markdown documentation generator
7.; |}
=== 39.7.; Етап 7.; Генерація та документація ===
- id: amount_gateway
4.; |-
|entity_id
|uuid/string
|ID документа або запису.; |-
|sla
|object
|Ні
|Загальні SLA процесу.; |-
|timeout
|integer
|Timeout запиту.; Exclusive Gateway.;=== Етап 5.; 39.5.; Валідація та симуляція ===
=== 26.1.; Мета симулятора ===
from: manager_approval
4.; |-
|approvers
|list
|Список погоджувачів.; користувач системи має змогу видалити вузол після підтвердження.; |-
|review
|Очікує перегляду.; |-
|condition
|expression
|Додаткова умова запуску.; |-
|completed_by
|reference
|Хто завершив.; |-
|Join Gateway
|join_gateway
|Обʼєднання паралельних гілок.;=== 14.1.; Призначення ===
{| class="wikitable"
version: 1
type: approval_task
!характеристика
↓
sla:
== 34.; Нефункціональні вимоги ==
1.; Результатом роботи редактора є собою структурований характеристика процесу у форматі '''YAML''', з якого можуть генеруватися виконувані workflow, код, конфігурації BPM-рушія, документація і інтеграційні сценарії.; |-
|YAML-first
|користувач системи редагує YAML, діаграма перебудовується після валідації.; 3.; |-
|start_process
|Запустити інший BP-процес.; Реалізувати actions для user/approval task.; !Тип
38.; Ризикиworkflow_handlers.py |
Тип
- reject Workflow engine / BPMN / код / документація Етап 6.; 39.6.; Runtime та публікація13.; |- |
Нова зміна = нова draft-версія | Для редагування released-процесу створюється нова реліз.; !характеристика | Тип
bp_process_variables 15.1.; Призначенняstatus: draft |
Тип дії
1.; платформа не надає можливість опублікувати бізнес-процес з Error.; {| class="wikitable" 20.2.; Приклади умов- id: t_start_manager Python workflow generator to: end_approved 39.; Рекомендований план реалізації |
Статус
purchase_approval.yml 1.; ↓ 11.1.; Призначення
|
escalation_after | Коли ескалювати після прострочки.; платформа знаходить переходи на неіснуючі вузли.; !характеристика | Джерело | Метод
2.; value: department_head
!Ризик
require_comment_on_reject: true
3.; |Створено рахунок.; |Оплата отримана.; Реалізувати YAML export.; |-
|webhook
|Запуск зовнішнім HTTP-запитом.; - id: t_manager_rejected
escalation_after: 1d
</pre>
=== 17.2.; Типи gateway ===
output: ./generated/bpmn
↓
<pre>
{| class="wikitable"
Для MVP достатньо:
label: Погодження фінансистом
Виконання процесу погодження закупівельна діяльність
escalation_after: 1d
3.; |-
| style="background:#d4edda; color:#155724; font-weight:bold;" |Рекомендовано
|Використовувати обмежену безпечну expression language.; |-
|Subprocess
|subprocess
|Виклик іншого бізнес-процесу.; Узгодити runtime-модель.; |-
|GET
|/api/bp-models/{id}/versions
|Отримати версії.; |-
|Нескінченний цикл
|Warning/Error
|Цикли мають бути явно дозволені.; |-
|system
|Системні змінні.;=== 14.2.; Типи системних дій ===
{| class="wikitable"
=== 32.1.; Імпорт ===
type: role
to: amount_gateway
- name: python_handlers
3.; ↓
4.; |-
|nodes
|list
|Так
|Вузли процесу.; * змінити статус документа;
* створити запис;
* оновити поле;
* сформувати друковану форму;
* створити задачу;
* провести документ;
* надіслати повідомлення;
* запустити інший бізнес-процес.; !Правило
- name: requester
module: purchases
== 13. Approval Task ==
status: rejected
{| class="wikitable"
</pre>
9.; |-
|started_at
|datetime
|Дата запуску.;=== 35.2.; Що можна відкласти ===
5.; |-
|Notification Task
|notification_task
|Надсилання повідомлення.; Модель зберігається в K2 ERP.; |-
|Мінімум один end node
|Error
|бізнес-процес має мати хоча б один фінальний вузол.; Released-версію не можна змінювати напряму.; 1.; |}
3.;== 26.; Симулятор процесу ==
allow_manual_start: true
|-
|approval_type
|enum
|single, sequential, parallel_all, parallel_any, majority.;== 22.; Повідомлення ==
6.;<syntaxhighlight lang="yaml">
!Тип
1.; AI-рекомендації по оптимізації процесу.; 11.; |-
|K2 Workflow Engine
|Високий
|Виконувана схема процесу.; |-
|label
|string
|Ні
|Назва переходу.; |}
- id: t_manager_approved
!характеристика
|
характеристика
System Task — автоматична дія, яку виконує K2 ERP без участі користувача.; 1.; |- |
Approval Task | approval_task | Задача погодження.;=== Етап 3.; 39.3.; Переходи та умови ===
- name: amount 21.; SLA та ескалаціїIntegration Task викликає зовнішній API або інтеграційний сервіс.; |- |
id | string | Так | Замовлення перейшло у статус “На погодженні”.; |} | Поле | Тип | Поле
approval_type: single
|