Якщо копнути глибше у тему візуального процесу створення програмних рішень – то є така річ як нотація моделювання бізнес-процесів (BPMN).
Якщо лаконічно пояснювати, то це стандартне графічне представлення моделювання бізнес-процесів. BPMN забезпечує просту у використанні нотацію з блок-схемою, яка не залежить від середовища реалізації.
Основна строгість підтримувати нотацію, що полегшує переклад моделей бізнес-рівня у виконувані моделі, які розпізнають BPM engines і механізми робочого процесу. Протягом останніх років BPMN широко застосовується у продуктах, пов’язаних з управлінням бізнес-процесами (BPM), зокрема, постачальниками інструментів як для аналізу та моделювання бізнес-процесів, так і самих BPM engines.
Розробники платформи MEF.DEV пояснюють: запропонований ними принцип роботи – це кількаступенева схема, яка враховує види, типи та організації бізнес-процесів за допомогою low-code програмування. Це деталізована, проте ефективна робоча модель.
Ось як це виглядає на практиці з конкретними прикладами. Все залежить від рівня реалізації задач. І, як і в будь-якому процесі, тут є поведінковий режим, активні та пасивні структури.
Бізнес-левел
На бізнес-рівні у загальному поведінковому вимірі дано: у паралельному шлюзі Parallel gateway на основі даних поєднуються кілька видів діяльності та колективні зусилля, які спрямовані на досягнення спільної мети (наприклад, активація послуг). В ексклюзивному шлюзі Exclusive gateway – мова йде вже про прийняття бізнес-рішень, які підпорядковуються певній багатозадачності (приклад – диференціація споживачів). Сервісна задача Service-task, яку при цьому потрібно вирішити розробнику – сформувати індивідуальний бізнес-процес, який продукують певні ролі (приклад – верифікація ролей у Business Support System (BSS). Базова скрипт-задача розробника застосунку Script-task наступна: ділова поведінка базується на ресурсах, а не на потоках (тут як приклад – webhook запит). Є і підпроцес Sub-process – коли ділова поведінка досягає конкретного результату, як заплановано у BPMN (наприклад, створити інвойс). При цьому, у подієвому контексті Event відбувається зміна стану, яка запускає або вривається в іншу бізнес-поведінку (зокрема, отримання нового інвойсу). Також у загальній структурі платформи є місце і для обробки зовнішнього процесу, тобто Сall-activity – розкриття функціональності інших бізнес-елементів (платіжний сервіс). Об’єкт взаємодії при цьому – пасивний елемент Data-reference, який має певну цінність з точки зору бізнес-перспективи (інвойс).
Програмний рівень
У паралельному шлюзі Parallel gateway визначається, які компоненти необхідні для виконання спільного завдання (приклад – Service Management API). В ексклюзивному Exclusive gateway – визначається спосіб, у який функціональні можливості компонента піддаються дії середовища (приклад – Customer Management API). Сервіс-задача Service-task тут описує користувацьку поведінку підключеного потоку процесу (приклад – надання привелегій щодо ролі користувача). Скрипт-задача Script-task представляє собою автоматизовану внутрішню поведінку компонента програми (транзакційний API медіації білінгу). Підпроцес Sub-process – це внутрішня поведінка, яку виконує програмний компонент для досягнення певного результату (створення інвойсу). Подієвий компонент Event – позначає зміну стану, яка може запустити/перервати поведінку іншого застосунку (запит на транзакцію). Зовнішній компонент Call-activity – представляє відкриту поведінку/функції застосунку (обробка транзакцій). Об’єктна опція Data-reference містить частину інформації у формі типу об’єкта (інформація по транзакції білінгу).
Технологічний рівень
Паралельний шлюз Parallel gateway на основі даних на цьому етапі – це кілька вузлів, які співпрацюють для виконання спільного завдання (приклад – налаштування (керування ресурсами). Ексклюзивний шлюз Exclusive gateway – визначає, як можна отримати доступ до функцій вузла (приклад – життєвий цикл клієнта (керування його обліковим записом). Сервісна задача Service-task тут – програмування специфічної поведінки кількох вузлів, що працюють разом у потоці процесу (приклад – авторизація користувача). В свою чергу, скрипт-задача Script-task – це коли внутрішня поведінка вузла може бути описана технологічною функцією (приклад – резервація коштів балансу користувача під час активації послуги Rating API). Підпроцес Sub-process на цьому рівні – це функція, подібна до технологічної, але яка більше зосереджена на послідовностях (приклад – кваліфікація послуги та визначення тарифу та правил нарахувань). Подієва складова Event реалізується в якості миттєвого елементу, який може бути тригером або переривати інші технологічні компоненти (приклад – запит на доступ до сервісу). Зовнішній компонент Call-activity розкриває функціональність вузла та робить його доступним публічно (приклад – управління даними (клієнт-менеджмент). Об’єкти Data-reference тут представлені у вигляді певних фізичних сутностей, якими може керувати технологічний рівень (приклад – артефакт).
Нижче це все зображено графічно на прикладі Телеком оператору:
• На технологічному рівні інтегровані системи BSS/OSS з різним програмним забезпеченням і даними пропонують доступ до даних задач застосунку за допомогою інтерфейсу відкритого API.
• Програмний рівень: до бізнес-процесів додаються прикладні завдання, які використовують технологічні компоненти. Елементи BPMN з повною логікою дозволяють працювати з настроюваним Omnichannel.
• Бізнес-рівень: процес замовлення та його окремі кроки, які обслуговуються певним застосунком.
Але насправді згадані способи, по суті, є точковим вирішенням і то фактично тих проблем, які вже виникли та відомі заздалегідь. А чи можливо підійти до питання комплексно? Як-то кажуть, діяти на упередження і там, де навіть важко робити прогнози щодо майбутніх ускладнень?
Як варіант – платформа MEF.DEV з автоматичною кодогенерацією моделей даних, що оновлюються, і які підтримують такі pattern як model-first і database-first, у тому числі з використанням reverse engineering підходу.
«Стандартизація моделей для кодогенерації дає можливість платформі під час завантаження кожного контейнера бізнес-логіки (NuGet) витягти дані атрибутів декораторів для технічної документації розробників із прикладами використання. Усі розробники бачать актуальну версію специфікацій завдяки тому, що це оновлення автоматизовано. Усі вимоги зведені до єдиного стандарту з функцією автооновлення», — розповідає Сергій Половников, фахівець компанії MEF.DEV.
Але це ще не все, функціональність та користь платформи для розробників на цьому не закінчується. За словами засновника проєкту, є ще референсна (послідовна за готовим рішенням) архітектура для калібрування процесів у великих компаніях.
Наявність вбудованих функцій DevOps у low-code платформі
Існує кілька систем і рішень, які забезпечують доступ до функціоналу DevOps (методологія автоматизації технологічних процесів складання, налаштування та розгортання програмного забезпечення).
Інженери MEF.DEV вважають, що головними тут є принципи гнучкості та інтегративності, які надають користувачу можливість на зрозумілому рівні взаємодіяти з різними застосунками, навіть і такими, які від розрізнених команд розробників.
Зокрема, один із головних аспектів MEF.DEV якраз і полягає в тому, що запропонована BPMN-code досить адаптивна, щоб дозволити клієнту інтегруватися з різними системами за допомогою різноманітних інструментів, наприклад, API, які зменшують складність інтеграції з механізмами CI/CD корпоративного рівня, як-от Jenkins і Azure DevOps.
Але це ще не все. MEF.DEV також надає користувачеві ще й опцію вбудованих функцій, які підтримують весь життєвий цикл програми.
Як це все працює? Насправді, зрозуміло і доволі нескладно:
• Розгортання за допомогою одного кліку: натисніть кнопку, і ви відкриваєте інтерфейс користувача, робочі процеси та компоненти серверної частини інтеграції, а механізм аналізу залежностей забезпечує працездатний стан усіх запущених програм.
• Легка міграція: опублікуйте нову версію, застосуйте зміни, а потім спостерігайте, як це відбувається. MEF.DEV перевіряє залежності та плавно розгортає програму в усіх середовищах.
• Операції та аналітика: ви можете усунути неполадки своїх додатків за лічені секунди завдяки зручним у використанні інформаційним панелям продуктивності, які створюються автоматично та допомагають вашій команді зосереджуватися і вирішувати найважливіші задачі.
• Управління: MEF.DEV обробляє конфігурацію та керування ідентифікацією запущених програм та їхніх залежностей у випадку розгортання групи програм.
• Вбудований контроль версій: потрібно повернутися до попередньої версії програми чи візуально об’єднати свою розробку? Нема проблем! Керування версіями MEF.DEV дає змогу інтуїтивно зрозумілими способами оперувати історією програм і підтримувати стратегію відкату.
Ця комбінація спрощує розгортання складної програми в робочій версії без необхідності створення сценаріїв або завдань вручну. Таким чином, платформа діє швидше та простіше за традиційні підходи.
Підсумки
Якісна BPMN-code платформа, по суті, вміє поєднувати непоєднуване – розробки від багатьох різноманітних команд, інтегрувати їх в певну єдину панель, завдяки чому клієнт має цілісне уявлення про архітектуру та взаємодію різних застосунків, може швидко їх інтегрувати, оперувати ними, розгортати та працювати. Навіть якщо мова йде не про одну програму, а про одночасне розгортання та управління декількома.
Це все суттєво полегшує розуміння та опановування процесів, економить ресурсні видатки, дозволяє швидше впроваджувати необхідні оновлення чи навпаки, робити відкати до первинної версії.