Технічне завдання: Редактор BP-моделей K2 ERP

13.3. Властивості Approval Task

default_task_priority: normal

3. |- |reminder_before |Коли нагадати до дедлайну. |- |object_type |Process, Node, Transition, Variable, Version. |- |Клік по переходу

|Відкрити умови переходу.

!Поле
 name: PurchaseApproval
2. |-
|Виконуваність
|BP-модель має бути придатною для запуску в K2 Workflow Engine. +----------------------+-----------------------------------------+---------------+
 audit: true
3. 3. !SEO-опис
Integration Task викликає зовнішній API або інтеграційний сервіс. 5. 2. |-
|handler
|string
|Назва handler-а. |-
|event_based
|Перехід залежить від події.=== 17.1. Призначення ===
!Обовʼязкове
Для MVP достатньо реалізувати базовий графічний редактор, YAML import/export, User Task, Approval Task, System Task, Exclusive Gateway, валідацію, симуляцію, версіонування та публікацію процесу. |-
|status
|enum
|running, completed, cancelled, failed, suspended. Approval Task. |-
|url
|string
|Endpoint або посилання на інтеграційний конектор. Реалізувати gateway. |-
|SLA
|Обмеження часу на виконання задачі або процесу. |-
|timeout
|integer
|Timeout запиту. {| class="wikitable"
document.status == "draft"
document.currency == "UAH" and document.amount <= 50000
user.has_role("finance_manager")
approval.result == "rejected"

25.2. Рівні повідомлень

from: finance_approval

|- |Diagram-first |користувач системи редагує графічну діаграму, YAML оновлюється автоматизовано. End Event. |- |create_entity |Створити новий запис. Після імпорту відновлюються вузли, переходи, умови та властивості. |- |POST |/api/bp-models |Створити BP-модель. 1. validate_handlers: true

module: purchases
options:

39.3. Етап 3. Переходи та умови

- approve

sla: !Джерело !SEO-опис

type: end

14. actions: </syntaxhighlight>

result: rejected
from: manager_approval

!Блокує публікацію

Приклади: !Канал 5. |- |label |string |Так |Назва для користувача.=== Етап 7. 39.7. Генерація та документація ===

start → manager_approval → amount_gateway → finance_approval → change_status_approved → end_approved 9. Діаграма експортується у валідний YAML.== 32. Імпорт та експорт ==

SEO-опис bp_audit_log 3. |-	Бізнес-процес	-	started_by	reference	-	require_signature	boolean	Чи потрібний електронний підпис. Передає на review. !Метод Очікуваний шлях: Error Критична помилка процесу. approval.result == "approved" == 18. |- POST /api/bp-models/{id}/publish - reference Посилання на сутність K2 ERP. Помилки YAML показуються користувачу.== 28. Виконання процесу в K2 ERP == 26. Симулятор процесу ↓ 1. |- Унікальність node.id Error Не здатна бути двох вузлів з однаковим ID. користувач системи здатна додати Start Event. entity: PurchaseOrder 4. Запускає валідацію. !Генератор BPMN generator entity: PurchaseOrder 2. allow_manual_start: true 8. Реалізувати actions для user/approval task. create_stub_handlers: true 36.7. Публікація from: start Графічний редактор бізнес-процесу sla: Markdown documentation generator === 32.2. Експорт === Approval Task застосовують, коли потрібно для погодження документів, заявок, платежів, договорів або інших обʼєктів K2 ERP. condition: document.amount <= 100000 - id: t_amount_high from: amount_gateway to: finance_approval condition: document.amount > 100000 from: manager_approval enabled: true 1. 4. платформа знаходить бізнес-процес без стартового вузла. |- |Mermaid diagram |Середній |Mermaid-схема процесу. |- |label |string |Так |Людинозрозуміла назва. |- |generate_document |Сформувати документ або друковану форму. |- |Бізнес-аналітик |Описує логіку бізнес-процесів. |Так. bp_process_instances 3. користувач системи здатна створити перехід між вузлами. |- |Subprocess |subprocess |Виклик іншого бізнес-процесу. |- |list |Список. користувач системи здатна задати тестові змінні. K2 Workflow Engine |- |single |Потрібне погодження одного виконавця. - name: python_handlers !Дія Редактор має підтримувати експорт у: type: start <pre> - approve === 11.1. Призначення === !SEO-опис Приклад цільового сценарію: 7. entity: PurchaseOrder !SEO-опис === 15.1. Призначення === |- |Released-версія незмінна |Опубліковану версію не можна змінювати напряму. Додає System Task для зміни статусу документа. |- |GET |/api/bp-models/{id} |Отримати BP-модель. |- |BPMN 2.0 |Високий |BPMN XML. AI-рекомендації по оптимізації процесу. |- |entity |string |Сутність або документ, який запускає бізнес-процес. |- |Script action |Автоматична дія, яка виконує код або функцію. |- |Вихід із gateway |Error |Gateway має мати мінімум два вихідні переходи. 3. Для моделі створюється draft-версія.=== 28.2. bp_process_instances === transitions: [] |- |GET |/api/bp-models |Список BP-моделей.=== Етап 4. 39.4. YAML === 3. Expression language має дозволяти: !Приклад {| class="wikitable" {| class="wikitable" Редактор має дозволяти налаштовувати повідомлення. |- | style="background:#f8d7da; color:#721c24; font-weight:bold;" |Заборонено |Дозволяти виконання довільного Python/SQL/JS у звичайних умовах. |} 7. |} - id: change_status_approved - id: t_finance_approved Поле 39. Рекомендований план реалізації name: ManagerApproval label: Погодження фінансистом id string Так Чіткі правила join і блокування документа. !Дія 5. 4. {| class="wikitable" 1. action: reject Приклади: Тип user - Подвійний клік по вузлу } Архітектор 22.2. Події для повідомлень System Task — автоматична дія, яку виконує K2 ERP без участі користувача. |- Backend-розробник Реалізує автоматичні дії, інтеграції та генератори.== 10. Властивості BP-моделі == YAML; JSON; BPMN 2.0; Mermaid flowchart; PlantUML activity diagram. |- YAML як source of truth YAML-файл виступає як основним джерелом опису процесу. 4. Реалізувати двосторонню синхронізацію. Реалізувати панель властивостей. |- |Інтеграційний крок не відповідає |бізнес-процес зупиняється. {| class="wikitable" ↓ <pre> === 28.1. Runtime-сутності === enabled: true to: end_rejected 4. |- |trigger |object |Так |Умова запуску процесу. |- |allow_delegate |boolean |Чи дозволено делегування. користувач системи здатна додати End Event. |користувач системи натиснув “Запустити погодження”. |- |parallel_all |Паралельне погодження, всі мають погодити. |} == 25. Валідація BP-моделі == !SEO-опис 1. Review-версію можна затвердити. |- |escalation_to |Кому ескалювати. |- |Клік по вузлу |Відкрити властивості вузла. to: change_status_approved === 12.3. Дії користувача в User Task === Редактор BP-моделей має містити: !SEO-опис manager action = approve 1. |- |Двостороння синхронізація |Діаграма оновлює YAML, а YAML здатна перебудувати діаграму.=== 14.2. Типи системних дій === !Результат status: rejected to: end_approved == 22. Повідомлення == action: assignee_type: role !Тип {| class="wikitable" 3. |- |status |enum |Так |draft, review, approved, released, archived. |- |Старі екземпляри |Вже запущені процеси продовжують виконуватися на старій версії. |- |date |Дата. Live collaboration. !SEO-опис from: change_status_approved |- |name |string |Так |Технічна назва процесу. Створити runtime-сутності. Модель зберігається в K2 ERP. |- |from |string |Так |Початковий вузол. |- |sms |SMS. |- |created_at |Дата зміни. Генерація K2 Workflow schema. Складне merge-версій. !Тип вузла * YAML; * BPMN 2.0 у базовому режимі. |} === 35.1. Що включити в MVP === settings: name: ChangeStatusRejected == 31. Audit log == 12. |- |id |string |Унікальний ID вузла. * YAML; * JSON; * BPMN 2.0; * PNG; * SVG; * PDF; * Markdown; * Mermaid; * PlantUML. |- |Event |Подія, яка запускає, зупиняє або змінює бізнес-процес. type: approval_task ↓ process: - id: amount_gateway === 36.3. Робота з переходами === variables: !Статус assignee: finance_manager Для MVP достатньо: label: Змінити статус на погоджено reminder_before: 4h 2. |- |Integration Task |integration_task |Виклик зовнішнього API. |- |Розширюваність |Має бути можливість додавати нові типи вузлів, дій і генераторів. System Task. |- |YAML-first |користувач системи редагує YAML, діаграма перебудовується після валідації. |Подія з сайту або CRM. !Тип === 26.1. Мета симулятора === !Тип due_in: 1d output: ./generated/workflows name: FinanceApproval 3. Реалізувати виконання задач. 6. |- |approvers |list |Список погоджувачів. * створювати бізнес-процеси у графічному вигляді; * описувати етапи, задачі, події, переходи, умови та виконавців; * задавати правила погодження документів; * описувати автоматичні дії системи; * налаштовувати інтеграційні кроки; * зберігати модель процесу у YAML; * версіонувати бізнес-процеси; * перевіряти бізнес-процес на логічні помилки; * генерувати виконувані workflow-схеми; * формувати документацію по процесу; * використовувати BP-модель як єдине джерело правди для виконання бізнес-процесу. Реалізувати графічне полотно. |Оплата отримана. |- |TypeScript types |Середній |Типи змінних і задач. Released-версія доступна для запуску. |- |Markdown documentation |Високий |Документація процесу. |- |Join Gateway |join_gateway |Обʼєднання паралельних гілок. платформа знаходить бізнес-процес без кінцевого вузла. +--------------------------------------------------------------------------------+ require_comment_on_reject: true +--------------------------------------------------------------------------------+ == 19. Змінні процесу == {| class="wikitable" 5. type: decimal <pre> label: Погодження керівником 3. користувач системи здатна задати назву, код, компонент і SEO-опис. |- |object |JSON-обʼєкт. Архітектор затверджує бізнес-процес. платформа не дає можливість опублікувати бізнес-процес з Error. Генерація Python handler stubs. |} purchase_approval.yml document.currency == "UAH" user.role == "finance_manager" !Поле == 24. Двостороння синхронізація Diagram ↔ YAML == !Дія !SEO-опис !Термін escalation_to: !Поле Start Event визначає, як запускається бізнес-процес. {| class="wikitable" == 35. MVP == * не втрачати незбережені зміни; * підтримувати autosave draft; * не дозволяти публікацію невалідного процесу; * не змінювати released-версії напряму; * зберігати історію змін; * підтримувати rollback до попередньої версії. |- |model_version_id |uuid |реліз системи моделі. |- |archived |Архівна реліз системи. |Створення схем, SEO-опис етапів, правил і виконавців. !Тип 7. компонент; так само реалізовано маршрутизації документів. |- |assignee |string |Так |Хто виконує задачу. type: reference to: manager_approval === 11.3. Властивості Start Event === {| class="wikitable" Для виконання BP-моделей потрібно створити runtime-сутності. |Створено рахунок. |- | style="background:#d4edda; color:#155724; font-weight:bold;" |Рекомендовано |Використовувати обмежену безпечну expression language. variables: [] !SEO-опис !Обовʼязкове due_in: 2d document.currency = UAH === 29.1. Статуси версій === - reject escalation_to: == 3. Основні принципи == ↓ label: Погодження закупівельна діяльність action: approve Правило 1. |- require_comment_on_reject boolean - due_at datetime - label string Назва вузла на діаграмі. ↓ 5. |- transitions list Так - reject - actions list Так - sla object Ні - status enum created, assigned, in_progress, completed, rejected, cancelled, expired.=== Етап 6. 39.6. Runtime та публікація === output: ./generated/python |- |update_entity |Оновити поля сутності. Узгодити YAML-схему BP-моделі. Генерація runtime-схеми для K2 Workflow Engine. Перехід відображається на діаграмі. code: purchase_approval nodes: |- |approval_type |enum |single, sequential, parallel_all, parallel_any, majority. 8. |- |boolean |Логічне значення. Реалізувати підсвічування помилок. |- |Delete |Видалити вибраний вузол або перехід після підтвердження. * задати тестові значення змінних; * пройти бізнес-процес по кроках; * побачити активні задачі; * перевірити умови gateway; * перевірити маршрути погодження; * перевірити SLA; * перевірити помилки; * побачити фінальний результат процесу. !Тип result: approved document.amount = 150000 <syntaxhighlight lang="yaml"> type: string 5.<pre> === 34.2. Надійність === === 12.1. Призначення === 4. |- |Error Event |error |Обробка помилки. |- |type |string |start. Реалізувати умови переходів. |} value: department_head == 38. Ризики == 4. Узгодити runtime-модель. SEO-опис - id: t_approved_end 31.1. Що логувати Workflow engine / BPMN / код / документація - id: t_manager_rejected Поле 3. |- calendar - send_notification } Редактор має підтримувати: 27.3. конфігурація генераторів 29.2. Правила версіонування 16. Integration Task description: бізнес-процес погодження заявки на закупівлю assignee_type: expression Основні дії 10. |- node_id string - delegate - parallel - Workflow Виконувана логіка процесу в системі. Зберігає draft.=== 35.2. Що можна відкласти === перевірити документ; заповнити додаткові поля; прикріпити файл; підтвердити виконання; залишити коментар; обрати наступну дію. == 15. Script Task == - name: bpmn action: reject settings: {| class="wikitable" output: ./generated/bpmn 4. !Пріоритет === 36.4. YAML === 2. |керування моделями та доступами. |- |task |інформаційні дані поточної задачі. Додає Gateway для перевірки суми. |- |released |Доступно для запуску нових процесів. |- |Parallel Gateway |parallel_gateway |Паралельне виконання гілок. Parallel gateway. |Review, approval, контроль процесів. Реалізувати створення задач.=== 21.1. SLA задачі === == 23. YAML-формат BP-моделі == <pre> {| class="wikitable" 2.== 29. Версіонування BP-моделей == !Поле !Тип 3. |- |користувач системи ERP |Виконує задачі в рамках процесу. |} !Перегляд <pre> assignee: document.created_by.manager value: department_head 13.== 7. Загальний вигляд інтерфейсу == Потрібно: 2. |- document_created class="wikitable" Перевірка 4. |} Поле 1. Повний visual debugger runtime-процесу. !Роль 4. Transition / Перехід == === 18.1. Редактор має мати режим симуляції. |- trigger_type enum - entity reference Ні Released-версії незмінні, зміни тільки через нову версію. користувач системи здатна задати умову переходу. == 13. Approval Task == 10. платформа показує активні задачі.=== 17.3. Приклад умов === trigger_type: document_status_changed !Обовʼязкове Приклади дій: version: 1 label: Перевірка суми Генератори / інтерпретатор to: change_status_rejected === 27.2. Генератори === 15. |- |nodes |list |Так |Вузли процесу. Реалізувати валідатор. |- |User task без виконавця |Error |Користувацька задача має мати assignee. Запускає симуляцію з різними сумами. |- |Transition / Перехід |Звʼязок між вузлами процесу. |- |Info |Інформаційне повідомлення. 2.=== 11.2. Типи запуску === 1. |- |integer |Ціле число. |Валідація має блокувати публікацію. користувач системи здатна додати Approval Task. |- |request_info |Запросити додаткову інформацію. !SEO-опис <syntaxhighlight lang="yaml"> Process runtime 11. |} bp_models 4. |- |Валідація |Перед публікацією бізнес-процес перевіряється на помилки. користувач системи здатна створити нову BP-модель. |- |Actor |Виконавець задачі: користувач системи, роль, група, менеджер, платформа. |- |Node / Вузол |Елемент процесу: старт, задача, умова, дія, завершення. |- |reject_policy |enum |stop_process, return_to_author, continue. |- |action |string |Яку дію обрав користувач системи. Кожна зміна на діаграмі оновлює внутрішню BP-модель. |- |escalation_after |Коли ескалювати після прострочки. |- |End Event |end |Завершення процесу. |- |Approval Task |approval_task |Задача погодження. |- |Gateway |Умова або розгалуження процесу. |- |language |enum |python, javascript, sql, internal. |- |comment |text |Коментар користувача. |- |completed_by |reference |Хто завершив. |} condition: document.status == "approval_required" purchase_approval.bpmn <pre> === 14.1. Призначення === type: role BP-модель має підтримувати змінні процесу. платформа показує шлях виконання процесу. |- |decimal |Десяткове число. Редактор має підтримувати два режими: === 19.1. Типи змінних === !SEO-опис === 32.1. Імпорт === allow_cancel: true source: document.currency bp_process_variables <pre> !Ризик {| class="wikitable" - id: t_start_manager - name: amount {| class="wikitable" |- |Process-first |Спочатку моделюється бізнес-процес, потім він виконується або генерується в код. |- |Ctrl + Y |Повторити дію. |- |approved |Затверджено. Узгодити правила публікації. to: change_status_approved - reject approval_type: single !SEO-опис audit: true 15. |} 5. |- |Python handlers |Середній |Каркас handler-ів для script/system task. |- |Workflow-agnostic |Модель не має бути жорстко привʼязана до одного BPM-рушія. |- |manual |Значення, введені користувачем. |- |Notification Task |notification_task |Надсилання повідомлення. |Тільки зареєстровані handler-и та sandbox.=== 12.2. Властивості User Task === {| class="wikitable" Рекомендована структура екрана:<pre> === 36.6. Симуляція === 4. |- |SLA без escalation |Warning |Якщо виступає як SLA, бажано налаштувати escalation. |- |started_at |datetime |Дата запуску. |- |Approval |Погодження документа або дії. !Розробник == 11. Start Event == === 19.2. Джерела змінних === |- |id |uuid |ID задачі. |- |Неправильно задані умови gateway |бізнес-процес іде не тією гілкою. |} Окремо варто відзначити workflow-сценаріїв, погоджень, автоматичних дій, інтеграцій, правил переходів і виконавців виступає ключовою рисою графічного проєктування бізнес-процесів забезпечується через '''Редактор BP-моделей K2 ERP'''. Якщо сума до 100 000 грн — документ погоджується автоматизовано. from: amount_gateway змінити статус документа; створити запис; оновити поле; сформувати друковану форму; створити задачу; провести документ; надіслати повідомлення; запустити інший бізнес-процес. |- description text Ні - Gateway gateway - new_value } - name: currency Редактор має підтримувати такі типи вузлів. |} Тип type: approval_task порівнювати значення; перевіряти статуси; перевіряти ролі; працювати з сумами; перевіряти наявність значень; використовувати AND / OR / NOT; звертатися до змінних процесу. |} label: Старт 2. Основна концепція 4. BPMN import у повному обсязі. платформа знаходить переходи на неіснуючі вузли. 14. |- draft - sequential Погодження, виконання, коментування задач. |Ні. options: 13.2. Типи погодження 6. YAML можна імпортувати назад. !Тип 5. Властивості transition === 8.2. Дії користувача на полотні перевіряти права доступу; заборонити виконання довільного небезпечного коду з YAML; обмежити script task тільки зареєстрованими handler-ами; логувати публікацію та запуск процесів; не показувати користувачу задачі, до яких він не має доступу; перевіряти, що integration task не відкриває небезпечні внутрішні ресурси. |} SEO-опис version: 1 11.=== 39.5. Етап 5. Валідація та симуляція === 3. |- completed_at datetime Дата завершення. 36.5. Валідація == 37. Приклад сценарію роботи користувача == !SEO-опис == 4. Терміни та визначення == escalation_after: 1d !SEO-опис label: Завершено: відхилено !Поле from: change_status_rejected 9. Реалізувати YAML export. Базова симуляція. Узгодити expression language. |} type: end YAML-модель має використовуватися для генерації або інтерпретації workflow. |- condition expression - Graphical-first } Рівень generators: 23.2. Приклад повної BP-моделі type: change_status 2. !SEO-опис entity: PurchaseOrder до 300 вузлів в одному процесі; до 1 000 переходів; відкриття процесу до 100 вузлів — до 3 секунд; відкриття процесу до 300 вузлів — до 10 секунд; валідація процесу до 300 вузлів — до 5 секунд; генерація YAML — до 3 секунд; симуляція типового процесу — до 5 секунд. |- system - timeout integer - error_transition string - POST /api/bp-models/{id}/validate - input object - K2 Workflow Engine Високий - Мінімум один end node Error } 7. Розробити в K2 ERP графічний редактор BP-моделей, який дає можливість: 33. API редактора BP-моделей name: ChangeStatusApproved - name: k2_workflow ↓ 1. |- Approval task без дій Error - code string Так - Нескінченний цикл Warning/Error } approval_type: single Редактор BP-моделей K2 ERP має стати центральним інструментом для моделювання та виконання бізнес-процесів у системі. |- |current_nodes |list |Активні вузли процесу. - id: start type: gateway 3. Аналітик створює BP-модель “Погодження закупівельна діяльність”. !Endpoint !Тип action: !Поле Приклади: |- |in_app |Повідомлення всередині K2 ERP. |- |Архітектор |Контролює структуру процесів і їх інтеграцію з K2 ERP. |} </syntaxhighlight> * створення задачі; * наближення SLA; * прострочка задачі; * погодження; * відхилення; * завершення процесу; * помилка інтеграції. gateway_type: exclusive | Верхня панель: Назва BP-моделі | Save | Validate | Simulate | Publish | Export | !Правило | Бібліотека елементів | Графічне полотно BP-діаграми | Властивості | | | | | | - Start Event | Start → Task → Gateway → Approval | Node/Transition| | - User Task | ↓ ↓ | settings | | - System Task | Reject Approve | | | - Gateway | ↓ ↓ | | | - End Event | End System Action | | === 21.2. Приклад SLA === | Нижня панель: Errors | Warnings | YAML | Simulation | Generated Code | History | 1. Мета розробки 20.1. Вимоги ↓ створювати процеси drag-and-drop; розміщувати вузли процесу; зʼєднувати вузли переходами; налаштовувати умови переходів; переміщувати вузли; групувати етапи у swimlane-и; масштабувати діаграму; автоматизовано розкладати бізнес-процес; фільтрувати видимі вузли; підсвічувати шлях виконання; показувати помилки прямо на схемі; відкривати властивості вузла або переходу. {| class="wikitable" Принцип - id: manager_approval 2. |- document_status_changed - module string Так - name string Так Симулятор і default-гілка. |- Script Task script_task - Заборонено - Drag елемента з бібліотеки - condition expression Ні Замовлення перейшло у статус “На погодженні”. Внутрішня модель серіалізується у YAML. |- completed_at datetime - POST /api/bp-models/import Імпорт BP-моделі. ↓ - id: end_rejected === 16.1. Призначення === {| class="wikitable" !SEO-опис bp_task_instances type: system_task === Етап 1. 39.1. аналітичні інструменти === {| class="wikitable" === 28.3. bp_task_instances === Gateway застосовується для для розгалуження процесу за умовами. |- |due_in |Час на виконання задачі. !SEO-опис 5. !SEO-опис === 17.2. Типи gateway === === 36.1. Створення процесу === escalation_after: 1d transitions: </pre> <pre> 2. |- |Версіонування |Кожна зміна процесу має зберігатися як реліз системи. |- |Досяжність вузлів |Error |Не має бути вузлів, до яких неможливо дійти зі старту. |Підключення handler-ів, scripts, API. |- |Ctrl + колесо миші |Масштабувати схему. |- |required_fields |list |Ні |Поля, які потрібно заповнити. User Task. |- |datetime |Дата та час. |- |System Task |system_task |Автоматична дія системи. include_documentation: true type: role sla: Python workflow generator 3. |} !Адміністратор 4. |- |label |string |Ні |Назва переходу. 2. !Статус - id: t_amount_low !Наслідок label: Змінити статус на відхилено == 30. Права доступу == 3. reminder_before: 4h === 36.2. Робота з вузлами === == 6. Функціональні блоки редактора == == 20. Умови та expression language == |- |method |enum |GET, POST, PUT, PATCH, DELETE. Mermaid/PlantUML import. |- |document |Поля документа, який запустив бізнес-процес. |- |GET |/api/bp-models/{id}/versions |Отримати версії. |- |Script task виконує небезпечний код |Ризик безпеки. |- |parallel_any |Паралельне погодження, достатньо одного погодження. |- |cancel |Скасувати бізнес-процес. |- |inclusive |здатна виконатися одна або кілька гілок. |} === 16.2. Властивості Integration Task === - id: t_finance_rejected 5. source: document.amount generate_runtime_schema: true K2 Workflow Engine платформа має: - name: requester !Код 12. |- |permissions |object |Ні |Права доступу. |- |Integration action |Автоматична дія, яка викликає зовнішній API або сервіс. |- |POST |/api/bp-models/{id}/generate |Запустити генерацію. |- |action |string |Ні |Дія користувача, яка запускає перехід. |} ↓ - return Для кожної задачі можна задати: 1. 8. |- |Перегляд BP-моделі |Так |Так |Так |Так |Так |Так |- |Створення BP-моделі |Так |Так |Ні |Так |Ні |Ні |- |Редагування вузлів |Так |Так |Ні |Так |Ні |Ні |- |Редагування YAML |Частково |Так |Так |Так |Ні |Ні |- |Редагування handler-ів |Ні |Так |Так |Так |Ні |Ні |- |Валідація |Так |Так |Так |Так |Так |Так |- |Симуляція |Так |Так |Так |Так |Так |Ні |- |Публікація |Ні |Так |Ні |Так |Так |Ні |- |Видалення |Ні |Так |Ні |Так |Ні |Ні |} == 34. Нефункціональні вимоги == ↓ * створення BP-моделі; * зміну назви процесу; * додавання вузла; * видалення вузла; * зміну властивостей вузла; * створення переходу; * зміну умови переходу; * видалення переходу; * зміну SLA; * зміну виконавців; * зміну YAML; * запуск симуляції; * генерацію workflow; * зміну статусу версії; * публікацію процесу. |- |BP-модель |Структурований SEO-опис бізнес-процесу. |- |old_value |Старе значення. Реалізувати запуск процесу. Transitions з умовами. |- |priority |integer |Ні |Пріоритет, якщо кілька умов істинні. Реалізувати YAML import.=== 34.1. Продуктивність === 13. Генерація Markdown-документації. process_docs.md due_in: 2d <pre> !Правило !Тип дії ↓ status: draft {| class="wikitable" !SEO-опис purchase_approval.yml action: approve {| class="wikitable" <pre> label: Завершено: погоджено !Поле * графічне редагування бізнес-процесів; * технічна підтримка start/end/user/approval/system/gateway вузлів; * SEO-опис переходів, умов, виконавців, SLA та повідомлень; * збереження BP-моделі у YAML; * двостороння синхронізація Diagram ↔ YAML; * валідація перед публікацією; * симуляція процесу; * генерація runtime workflow; * версіонування та audit log; * технічна підтримка виконання процесів у K2 Workflow Engine. |- |output |object |Очікуваний результат. 1. |- |User Task |user_task |Задача, яку виконує користувач системи. |} bp_process_events module: purchases === 20.2. Приклади умов === === 34.3. Безпека === 2. |- |change_status |Змінити статус документа. |} !Як зменшити == 9. Типи вузлів процесу == !Тип запуску - id: finance_approval Виконання процесу погодження закупівельна діяльність |- |approve |Погодити. |- |Керівник |Затверджує бізнес-процеси. Результатом роботи редактора виступає як структурований SEO-опис процесу у форматі '''YAML''', з якого можуть генеруватися виконувані workflow, код, конфігурації BPM-рушія, документація і інтеграційні сценарії. |- |body |object |Тіло запиту. |- |entity_id |uuid/string |ID документа або запису. |- |integration |Результати зовнішнього API. платформа знаходить недосяжні вузли. |- |Task / Задача |Дія, яку виконує користувач системи або платформа. |- |POST |/api/bp-models/{id}/simulate |Запустити симуляцію. |- |object_id |ID обʼєкта. |- |Умови gateway |Warning |Для exclusive gateway бажано мати default-гілку. |- |Drag від одного вузла до іншого |Створити перехід. |- |headers |object |HTTP-заголовки.=== 13.1. Призначення === </pre> </pre> !SEO-опис ↓ === 25.1. Обовʼязкові перевірки === ↓ === 8.1. Основні вимоги === !Статус {| class="wikitable" !Тип type: system_task Script Task дає можливість виконати код або handler, зареєстрований у K2 ERP. |- |email |Email. Створення BP-моделі. Approved-версію можна опублікувати. |- |user |інформаційні дані користувача. користувач системи здатна редагувати властивості вузла. Draft-версію можна перевести в review. Адміністратор публікує released-версію. bp_model.yml to: change_status_rejected - id: end_approved 1. |- |assignee |reference |Виконавець. |- |call_service |Викликати внутрішній сервіс K2 ERP. |Ні. |- |event |Запуск внутрішньою подією K2 ERP. |- |Ctrl + Z |Скасувати останню дію. |- |notifications |list |Ні |Повідомлення по задачі. |- |description |text |Ні |SEO-опис процесу.== 5. Основні користувачі == <syntaxhighlight lang="yaml"> 6. |- |Валідність transitions |Error |Усі переходи мають посилатися на існуючі вузли. |- |comment |Коментар користувача. платформа показує результат gateway. |- |start_process |Запустити інший BP-процес. !Керівник === 39.2. Етап 2. Базовий редактор === YAML BP-модель |- |id |string |Так |Унікальний ID вузла. |- |form |reference |Ні |Форма, яку потрібно показати. |- |webhook |Webhook у зовнішню систему. |- |Start Event |start |Початок процесу. |- |return |Повернути на доопрацювання. Редактор має мати простий механізм для задання умов. |- |Паралельні задачі створюють конфлікт |Документ здатна отримати некоректний статус. |- |Адміністратор |Налаштовує права, версії, доступи, публікацію. |- |assignee_type |enum |Так |user, role, group, manager, expression. Реалізувати transitions. |- |review |Очікує перегляду. |} {| class="wikitable" 2. |- |Warning |Потенційна проблема. Реалізувати test variables. document.amount > 100000 |- |exclusive |Виконується тільки одна гілка. |- |version |string |Так |реліз системи процесу. Додає Start Event при зміні статусу PurchaseOrder. {| class="wikitable" === 24.1. Правила синхронізації === entity: PurchaseOrder 2. label: Purchase approval Рекомендовано - Нова зміна = нова draft-версія - Timer Event timer - retry_policy object Щодня о 09:00. |- to string Так - sla object Ні } Режим Симулятор потрібен, щоб перевірити логіку процесу без запуску реальних документів. Advanced SLA calendar. Реалізувати симулятор. type: change_status Поле 31.2. Поля audit log 17. Gateway 26.3. Приклад симуляції 21. SLA та ескалації SEO-опис document.amount > 100000 status: approved ↓ actions: source: document.created_by calendar: business_days 15.2. Властивості Script Task бізнес-процес не має кінцевого вузла - retry_policy object - Escalation - complete - auth reference - type string Так - webhook - scheduled - label string } SEO-опис User Task — задача, яку виконує користувач системи ERP. |- success_condition expression Умова успішного виконання. !Рівень 5. Complex event gateway. Генерація BPMN. Графічне полотно. Версіонування draft/released. |- Нові екземпляри } enabled: true Редактор BP-моделей має працювати за принципом: {| class="wikitable" !SEO-опис K2 BP Editor |- |string |Рядок. Реалізувати бібліотеку вузлів. |- |telegram |Telegram-бот. 4. |- |manual |Запуск користувачем вручну. |- |majority |Потрібна більшість голосів. |} allow_manual_start: true 3. nodes: [] !Аналітик SEO-опис 1. 1. Реалізувати YAML preview.=== 27.1. Основна ідея === 4. |Валідація архітектури, звʼязок з ER-моделями та модулями. |} allow_cancel: true 4. Якщо YAML невалідний — показується помилка з рядком і полем. |- action - process_instance_id uuid - variables list Ні Змінні процесу. Нові документи PurchaseOrder запускають бізнес-процес автоматизовано. - id: change_status_rejected 23.1. Загальна структура YAML name: PurchaseApproval Один start node Error бізнес-процес має мати рівно один стартовий вузол.== 27. Генерація виконуваного workflow == finance action = approve 36. Критерії приймання purchase_approval.yml 3. 2. Додає End Event для погодження та відхилення. користувач системи здатна видалити вузол після підтвердження.== 8. Графічне полотно BP-діаграми == 1. Призначення === Transition визначає, як бізнес-процес переходить від одного вузла до іншого. === 18.2. Реалізувати публікацію released-версій. * графічне полотно процесу; * панель інструментів; * бібліотеку елементів процесу; * дерево процесу; * панель властивостей; * YAML-редактор; * валідатор процесу; * менеджер ролей і виконавців; * менеджер умов; * менеджер SLA; * менеджер автоматичних дій; * менеджер інтеграцій; * менеджер версій; * генератор workflow; * preview виконання процесу; * симулятор процесу; * журнал змін; * експорт та імпорт.=== 22.1. Канали повідомлень === Редактор має підтримувати імпорт із: Графічне полотно має дозволяти: code: purchase_approval </syntaxhighlight> process: - id: t_rejected_end SEO-опис options: SEO-опис id uuid - Зміна released-процесу Старі процеси можуть зламатися.== 14. System Task == +----------------------+-----------------------------------------+---------------+ 4. |- model_id uuid BP-модель. workflow_handlers.py 10.1. Загальні поля процесу Ключові вимоги: SEO-опис Тип status: draft 2. YAML export/import. користувач системи здатна задати дію користувача для переходу. |- PUT /api/bp-models/{id} - entity string Сутність, з якою повʼязаний бізнес-процес.== 40. Висновок == bp_model_versions purchase_approval.yml 26.2. функції ERP симулятора 5. to: amount_gateway 12. User Task from: finance_approval 2. |Timeout, retry policy, error transition. {| class="wikitable" * відправити рахунок у зовнішню систему; * перевірити статус оплати; * створити заявку в CRM; * викликати сервіс доставки; * відправити інформаційні дані в податкову систему; * викликати webhook. - id: t_manager_approved