Новая версия 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 и c 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 счет, можно ввести понятия бесконечного процесса, как банковского счета, где каждый аменд или шаг выполнения — это транзакция, которая либо переводит между аккаунтами банка либо задействует коннекторы и шлюзы в фиат и биткоины.

Такая фундаментилизация бизнес-процессов хорошее упражнение для энтепрайз долбоебов, которые не знают с чего начинать ассесмент. Начинать надо с самого главного, того процесса который приносит бабки и где спрятан весь биллинг. Все остальное над этим процессом — это его объязка: открытие счета, закрытие, пополнение, снятие, и трансфер как управляющие аменды.

В будущем полноценный рабочий опен соурс банк ждите по этому адресу:

synrc/bank — 4.4

JSON API

Для поддержи привычного представление бизнес-объектов в виде JSON на стороне клиента используется библиотека BERT:

synrc/bert

С помощью специального parse_transform генерируется JavaScript SDK для всех рекордов описаных в type spec. Как же пользоваться и проверить что всё работает? Смотрите как проверить прямо в браузере. Заходите на bank.n2o.space или bpe.n2o.space и открывайте 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":"[email protected]"}}

Кстати обертка 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. Я согласен перейти на что угодно, что позволит повысить формальность и сократит размер.