Нова версія BPE 4.4

BPE - це легковажна система управління бізнес-процесів створена для вбудовування в ерланг додаток, на якій написана сторінка депозитів pb.ua/depozit. Як, ви знаєте, ми давно обіцяли Open Source Банк, як демо додаток на N2O стеку, який використовує не тільки NITRO, а й FORMS та BPE – систему документообігу та управління бізнес-процесами - святий грааль бізнес девелопменту. Завдяки щасливому випадку, я колись писав master thesis на цю тему, тому у мене на руках кілька формальних моделей і декілька імплементацій (.NET, Erlang). BPE - це топчик, який працює по суті на голому gen_server, а в якості зберігання трейсів процесів використовує двозв'язкові списки (KVX), які можуть зберігатися у будь-яких базах. Тут ми опишемо квітневі модифікації (кодова назва VARNA), які були проспонсовані компанією Quanterall. [Якщо все піде добре, то можливо ми розширимо присутність N2O стека на Elixir, проект O73]

— github.com/synrc/bpe — 4.4

Кодова назва цієї версії VARNA, оскільки комміти були зроблені в цьому місті в офісі компанії Quanterall; ми плануємо з ними у майбутньому виконати порт на Elixir платформу, завдяки чому поширимо присутність BPE та інших продуктів SYNRC на Elixir екосистему також.

Нововведення

Сумісність з MIX і REBAR3

Тут довелося повернутися з {tag,master} тому що rebar3 не розуміє [], на який ми перейшли в MAD. Тепер усі бібліотеки працюють і з MAD, і з REBAR3 і з MIX. У наступних версіях з'явиться підтримка рідного Elixir додатка топлевела, яке буде імпортувати через Record.extract основні схеми SYNRC стека.

Квітневий роллаут

Разом з BPE оновлено цілу серію додатків, так як BPE використовує атоматичний JSON генератор (json-bert.js) через BERT додатки, і вимагає модифіковану версію MAD, яка за один прохід генерує файл та компілює його. Також було оновлено бібліотеку FORMS, серце генераратора форм.

— synrc/forms — 4.4
— synrc/nitro — 4.4
— synrc/n2o — 6.4
— synrc/mad —5.4

Автогенеровані форми

У системах управління бізнес-процесами (СУБП) прийнято використовувати максимально декларативну модель опису, тому для кожного кроку можна та потрібно перерахувати список документів або повідомлень, які тригерят конкретний перехід на конкретному кроці керуючого FSM. Для цього в BPE додалося поле prompt, в якому ми зберігатимемо список документів, які мають бути правильно заповнені для успішного проходження конкретного кроку.

Раніше використовувалися автономні контролери, для кожного BPE бізнес-процесу писалася супровідна NITRO сторінка, яка ним керувала, в якості веб-контролера. Я казав, що це хуйня, тому що треба написати абстрактний формо-генератор і запитувати лише ті документи, які прописані в prompt і таким чином можна побудувати систему, де не потрібно буде вручну писати веб-контролери процесів. Поле prompt — перший крок на шляху до цього процесу, в наступних версіях буде представлений універсальний адміністративний редактор управління бізнес-процесом, наприклад, як контрольний елемент #bpe{} бібліотеки NITRO.

Адмінка на NITRO

У цій версії з'явилася проста адмінка на NITRO, яка дозволяє поки що тільки створювати процеси та проклацувати їхню структуру. Окрема простенька сторінка для трейсів процесів, що у банку, наприклад, буде історією транзакцій за рахунком.

Візуальні редактори графів

BPE - це система управління процесами DEVELOPER FIRST (девелопери самі підтримують декларативні символьні та графічні описи). Тому, що ми вважаємо, що декларативний формальний синтаксис кращий за графічну нотацію. Графічну нотацію ми не скасовуємо та плануємо генерувати візуальне зображення FSM процесу за допомогою автоматичного лейауту. Не багато існуючих редакторів таке вміють. Але, припустимо, ми самі навчилися робити аутлейаут зовнішніми препроцесорами, тоді друга фіча, яка множино відсутня в існуючих редакторах — це можна навішувати теги на сутності, переходи, документи, і не просто теги, а можливо туди вписувати правила певної BNF нотації, за якою можна було б згенерувати і код і дані, наприклад, ті ж документи, які необхідні для заповнення на поточному кроці. Таким чином існує цілий клас параметрів, які у різних місцях мають задаватися у графічному редакторі. Подужати такі вимоги можна тільки сівши і написавши все самому. Тому BPMN.io і ще ряд інших графічних редакторів відпали. До того ж якщо й робити, щось варте те як мінімум не гірше ніж у Corezoid, а там гарні криві були. Схожі красиві криві зробили наші друзі з Казані на сайте bot-crm.ru (на N2O і NITRO до речі!).

Загалом графічний редактор - це окремий великий незакритий гештальт! Сподіваємося, що найближчим часом щось має з'явитися!

Нові приклади бізнес-процесів

Щоб показати фундаментальну важливість бізнес-процесів, як молотка яким можна все забивати, покажемо вам, як можна замість ERP сутності IBAN рахунок, можна ввести поняття безскінченного процесу, як банківського рахунку, де кожен аменд чи крок виконання – це транзакція, яка або переказує між аккаунтами банку або залучає конектори та шлюзи у фіат та біткоїни.

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

У майбутньому повноцінний робочий опенсорс банк чекайте за цією адресою:

— erpuno/fin — 4.4

JSON API

Для підтримки звичного представлення бізнес-об'єктів у вигляді JSON на стороні клієнта використовується бібліотека BERT:

— synrc/rpc

За допомогою спеціального parse_transform генерується JavaScript SDK для всіх рекордів, описаних в type spec. Як же користуватися та перевірити, що все працює? Дивіться, як перевірити прямо в браузері. Заходьте на bank.n2o.dev або bpe.n2o.dev та відкривайте JavaScript консоль:

> $io.do = function(r) { console.log(decode(r)); };

тепер можете надіслати ініціалізуючий маркер, для того щоб перемалювати сторінку і викликати NITRO метод event(init).

> ws.send('N2O,');
{tup: "io", code: "var x = qi('stand'); ... ", data: {tup: "Token", data: "db3b5bc4fd9a59907f12def5c77fb868d5 b35cb22c9756f182…7d29875bb699ba05c 69614e4930da39da127bfb43e698bd10"}}

Переконайтеся, що ви створили хоча б один процес перед виконанням операції завантаження процесу #load{id=1}:

> ws.send(enc(encode({tup:'load',id:1})));
{"tup":"io", "data":{"tup":"process", "id":1, "container":"feed", "feed_id":"process", "next":2, "name":"IBAN Account", "tasks":[{"tup":"userTask","name":"Init","module":"bpe_account"}, {"tup":"userTask","name":"Upload","module":"bpe_account"}, {"tup":"userTask","name":"Signatory","module":"bpe_account"}, {"tup":"serviceTask","name":"Payment","module":"bpe_account"}, {"tup":"serviceTask","name":"Process","module":"bpe_account"}, {"tup":"endEvent","name":"Final","module":"bpe_account"}], "events":[{"tup":"messageEvent","name":"PaymentReceived"}], "flows":[{"tup":"sequenceFlow","source":"Init","target":"Upload"}, {"tup":"sequenceFlow","source":"Upload","target":"Payment"}, {"tup":"sequenceFlow","source":"Payment","target":["Signatory","Process"]}, {"tup":"sequenceFlow","source":"Process","target":["Process","Final"]}, {"tup":"sequenceFlow","source":"Signatory","target":["Process","Final"]}], "docs":[{"0":"tx","tup":"$"}],"task":"Process","started":"nonode@nohost"}}

До речі, обгортка N2O протоколу навколо BPE займає 7 рядків. Автоматичний маршалінг параметрів дозволяє нам автоматичну публікацію RPC сервісів по шині, як у SOAP та старому доброму ентерпрайзі! До мікросервіс-божевілля та GRPC ми теж готові, його ми теж генеруємо і навіть присутні на офіційній сторінці awesome-grpc. Користуючись нагодою хочеться передати привіт всім довбойобам, які використовують GRPC у себе у виробництві! Нагадую, що GPB либа Томаса Абрамсона на Ерланзі займає 80 000 рядків коду, а наш генератор 140.

Плани на майбутнє

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

Amend per History record 4.5

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

KVX back-end 4.6

Потрібно перейти з KVS на новішу та мінімалістичну бібліотеку KVX. Можна перейти з gen_server на N2O-шний новий n2o_pi. Я згоден перейти на будь-що, що дозволить підвищити формальність і скоротити розмір./p>