Продуктивність роботи BPMN low-code платформ

Уся якість роботи систем BPMN (Business Process Model and Notation) безпосередньо залежить від того, наскільки ефективною є взаємодія між програмним продуктом та кінцевим споживачем. Тут мається на увазі чіткість і швидкість реакції, точність, з якою той чи інший застосунок обробляє запит, кількість можливих взаємодій за одиницю часу або під час виконання транзакції. Метод поділу транзакцій за допомогою більш простого та уніфікованого методу називається обробкою транзакцій, який є основою щодо будь системи обробки транзакцій (Transaction Processing System).

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

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

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

Зауважимо, що це поширена помилка, коли платформи з Low-code або No-Code, з їх розгалуженою системою інструментів та концепцій, створюють програми, які працюють повільно, без можливості оптимізації через рівні, які знаходяться над фактичним доступом до даних і їхньою обробкою. Що й казати – проблема актуальна, але є способи вирішити це та зберегти для продукту переваги ефективного процесингу low-code опцій.

Високорівневі оптимізовані «рекомендовані» компоненти

Сучасні BPMN-low платформи містять доволі жорсткі директивні компоненти, які спроєктовані та створені для бездоганної та ефективної спільної роботи.

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

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

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

Фахівці mef.dev підмічають: якість та продуктивність виконання програм для платформ BPMN low-code залежить від наявності в них цілісно скомпільованої та оптимізованої для транзакційного виконання версії застосунку, причому виконаною саме мовою програмування замість інтерпретованого скрипта.

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

Підхід «на рівні ядра»

«На рівні ядра» — це термін, який використовується в програмуванні, що означає надання прямого доступу до потрібного ресурсу. Деякі low-code платформи дозволяють організувати і надати прямий доступ, тобто, зберігаючи переваги низького коду, вони також дають розробнику можливість проводити подальшу оптимізацію на рівні ядра системи, причому здійснювати це за необхідності у складних базових системах, які можуть цього вимагати. Типовим прикладом тут є те, як low-code платформи надають можливостей керування даними.

Два основних підходи до управління даними:

1. Приховати фактичну базу даних та надати користувачеві інструментарій моделі даних вищого рівня – об’єктне реляційне відображення даних Object-Relational-Mapper (ORM), яка оперує усією вихідною інформацію та може здійснювати трансформації цих даних автоматично та непомітно для розробника.
2. Надати прямий доступ до бази даних і зробити так, щоб платформа обробляла дата-схему у гнучкіший спосіб, фактично за директивнім інструкціями розробника.

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

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

На практиці досвідчені архітектори (Software architect) використовують обидва підходи та нівелюють ризики продуктивності закладаючи можливість вибору стратегію по роботі з даними, а саме – базова розробка на підставі ORM підходу та застосуванням слабо-пов’язаного коду (об’єднання слабо залежних один від одного шматків коду на льоту за рахунок технологій управління інверсією (inversion of control) і впровадження залежностей (dependency injection) задля критичних елементів систем або інтеграції систем (System integration).

Яка різниця між мовами сценаріїв і програмування?

По суті, усі мови сценаріїв є мовами програмування. Теоретична різниця між ними полягає в тому, що мови сценаріїв не вимагають етапу компіляції та інтерпретуються під час виконання. Наприклад, зазвичай програму на C потрібно скомпілювати перед запуском, тоді як у звичному форматі роботи мова сценаріїв, як-от JavaScript або PHP, цього не потребує. Однак, це не завжди актуально. Як вже зазначалося, в питанні продуктивності виконання у BPMN low-code все ж таки першу скрипку грають мови програмування зі скомпільованими версіями продукту, а не інтерпретовані скрипти (сценарії).

І от чому.

Як правило, скомпільовані програми працюють швидше, ніж інтерпретовані, тому що вони спочатку конвертуються у «рідний» машинний код. Крім того, компілятори читають і аналізують код лише один раз і спільно повідомляють про помилки, які можуть бути в коді, але інтерпретатор читатиме та аналізуватиме оператори коду щоразу, коли він їх зустріне, і зупинятиметься лише тоді, коли натрапить на якусь помилку. На практиці ж різниця між скомпільованими та інтерпретованими продуктами може бути дещо розмитою завдяки вдосконаленим обчислювальним можливостям сучасного апаратного забезпечення та прогресивним методам кодування. Але ми ж розуміємо – навіть невелика різниця між мовами та стандартами означає затримку, в тому числі й в часі, а час – це збільшення показника TPS (Transactions_per_second).

Ще один момент, який слід зазначити, полягає в тому, що класифікуючи мову як мову сценаріїв або мову програмування, слід враховувати середовище, в якому вона буде виконуватися. Причина, чому це важливо, полягає в тому, що ми можемо розробити інтерпретатор для мови C і використовувати його вже як мову сценаріїв, і в той же час як можна розробити компілятор для JavaScript і використовувати його як мову без сценаріїв (компільовану мову). Середовище виконання — це стан цільової машини, який може включати бібліотеки програмного забезпечення, змінні середовища абощо, аби забезпечувати процеси, які є в системі. Живим прикладом цього є V8, механізм JavaScript Google Chrome, який за рахунок компілятора JIT (Just-In-Time) компілює код JavaScript у машинний код, а не інтерпретує його.

Зазначимо приклади мов програмування, які традиційно використовуються з певним кроком компіляції – це C, C++, Java та С#. При цьому приклади мов сценаріїв, які традиційно використовуються без явного кроку компіляції, це, зокрема, JavaScript, PHP, Python, та VBScript. Розглянемо відмінності у вигляді таблиці:

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

В якісно спроєктованій BPMN low-code платформі елементи не впливають на загальну ефективність системи, оскільки продуктивність вже як така закладена в самій low-code архітектурі і компонентах системи. Якщо цього вимагає складність проєкту, то деякі low-code платформи, користуючись підходом «на рівні ядра», відкривають можливість для конкретної оптимізації.

Отже, коли ми говоримо про продуктивність BPMN low-code платформ, то мусимо передбачити: аби вони були швидкими та адаптивними – вони мають бути скомпільовані для миттєвого самовиконання, а не бути орієнтовані на виконання у середовищі інтерпретатору, радять фахівці mef.dev.

Системи low-code та BPM: консолідація чи навпаки?

Сучасні методи Low-code рішень щодо BPMN: цифровий суверенітет та ергономіка ресурсів