Аудит бізнес-процесів

Використовувати в сервісних задачах X-Access-Token, який був отриманий в поточній транзакції бізнес-процесу

При використанні juel функцій для отримання користувацького авторизаційного токену (наприклад, completer('ActivityId').accessToken, initiator().accessToken) треба впевнитись, що місце використання функції та відповідна актівіті (користувацька задача, або початкова подія) знаходяться в одній транзакції бізнес-процесу.

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

Використовувати токен користувача найближчої до точки використання задачі або токен системного користувача (system_user().accessToken)

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

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

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

В задачах транзакції проставляти атрибути camunda:asyncBefore або camunda:asyncAfter зі значенням true для асинхронного продовження (Asynchronous Continuations) бізнес-процесу, що призведе до створення нової транзакції. Додатково слід враховувати роботу з користувацьким токеном (BP-01. X-Access-Token в сервісних задач) та несталими змінами (BP-07. Робота з несталими (transient) змінними) при моделюванні асинхронних задач.

При наявності циклів в бізнес-процесі, розпочинати кожну ітерацію в окремій транзакції

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

При наявності циклів, які мають велику кількість ітерацій Camunda Engine тримає транзакцію на базі даних протягом всього часу його виконання, що може призвести до впливу довгих транзакцій, які описані в BP-02. Довгі транзакції бізнес-процесів. Додатково слід зауважити, що при виникненні помилки на 100-ій ітерації, буде спроба виконати всі ітерації, починаючи з першої.

Проставляти camunda:asyncBefore атрибут після першої актівіті у циклі (це може бути сервісна задача, або початкова подія у випадку під-процесу) або camunda:asyncAfter останньої актівіті у циклі. Потрібно також врахувати та виключити використання несталих (transient) змінних, які були отримані у бізнес-процесі до першої операції у циклу.

Перевизначати стратегію повторних спроб (retry time cycle) для асинхронних задач.

За замовчуванням при виникненні помилки при виконанні асинхронних задач виконавець робіт (job executor) буде пробувати виконати задачу ще 3 рази без пауз між ними. У більшості випадків причиною помилки може бути виклик іншого сервісу як всередині системи, так і за її межами, який міг бути тимчасово недоступний. В такому випадку негайний повтор не призведе до якихось змін і врешті решт задача буде помічена невдалою (failed) і може бути перезапущена тільки вручну Адміністратором реєстру у Сервісі адміністрування бізнес-процесами

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

Для асинхронних задач встановити атрибут циклу повторних спроб camunda:failedJobRetryTimeCycle з певною затримкою, наприклад, 5 спроб кожні 5 хвилин R5/PT5M. В процесі експлуатації значення може бути адаптоване відповідно до поведінки бізнес-процесу.

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

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

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

Завжди вказувати параметр ліміту (limit) для сервісних задач з пошуку даних. Можливі сценарії використання:

При використанні скриптових задач слід уникати складної логіки і робити їх якомога простішими.

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

Важливі аспекти, пов’язані з використанням складної логіки в скриптових задачах:

При моделюванні бізнес-процесів слід враховувати, що деякі змінні можуть бути несталими (transient) та не зберігатись при переході на наступну транзакцію.

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

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

Для збереження складної сутності та транзакційного запису в декілька таблиць використовувати функціонал вкладених сутностей (nested entity).

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

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

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

Присвоювати технічно доречні ідентифікатори всім елементам бізнес-процесу в BPMN діаграмі.

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

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

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

Орієнтуватися на офіційну документацію Camunda з кращих практик моделювання BPMN діаграм. Деякі з рекомендацій наведені нижче:

При моделюванні циклів розглянути можливість використання багатоекземплярних (multi-instance) підпроцесів замість циклів з використанням шлюзів (gateways).

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

Часто в скриптових задачах використовуються методи print / println для логування даних в консоль, що є припустимим при розробці бізнес-процесу, але не прийнятно для промислових середовищ.

Використання методів print / println в скриптових задачах призводить до логування інформації в Сервісі виконання бізнес-процесів, які надалі не можна пов’язати з конкретним бізнес-процесом та запитом користувача.

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

Регламент реєстру не є захищеним сховищем і зберігання токенів в ньому може призвести до їх витоку і використання третіми особами.

Всі авторизаційні токени для викликів зовнішніх сервісів повинні бути зареєстровані відповідно до документу

При роботі з бізнес-процесами реєстру відповідальні особи працюють з користувацькими задачами (user task), які були на них призначені і які з тих чи інших причин можуть бути виконані та забуті. Одним з можливих рішень є використання таймерів з автоматичним завершенням бізнес-процесу

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

На користувацьких задачах, що потенційно можуть бути забуті, рекомендується використовувати timer boundary event, який по закінченню налаштованого часу автоматично буде переривати виконання бізнес-процесу та призводити до його завершення. Додатково можна розглянути виділення критичних секцій в підпроцеси і використання такого роду івентів на них.

Уникати дублювання однакових послідовностей блоків при моделюванні бізнес-процесів

Задавати бізнес-ключ бізнес-процесу (business key) якомога раніше в процесі його виконання

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