2. Микросервис
1. Хороший вопрос...
Последнее время я в основном наблюдаю одно и то же. Люди используют камунду для построения саги, встраивают ее в синхронную обработку http запросов, пытаются строить low latency приложения. И естественно во всех этих сценариях камунда показывает себя посредственно, т.к. изначально не предназначена для подобного рода задач. Но тем не мене, запрос от сообщества есть. И чем производительнее будет камунда, тем лучше

ну основные задержки камунды связаны с огромным числом записей которые создаються потом удаляются по мере движения по процессам. Поэтому скорость почти напрямую связана с БД которая используется. А убрать саму схему "statefull" при переходе от одного элемента к другому.... наверное в принципе нельзя ... ибо это ядро системы

Поэтому тут скорее вопрос к движкам баз

Ну не только. Еще все-таки и к использованию этих самых баз.
Конкретно сейчас у меня проблема с запуском сервиса из-за разросшейся таблицы act_ge_bytearray.
Плохая идея хранить в одной таблице исходники схем и значения переменных процессов.

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

Привет. Смотрите в history методах. Потому что в рантайм сущностях насколько я помню вообще нет никаких записей времени

Действительно есть такой спасибо

Документооборот не делай, саги не делай. А что делать то можно?) И ещё там где не нужен перформанс

Процессное управление бизнесом делай ))))

Да там больше половины сводится к юзер таскам и транзакциям))

👍

😁

> Люди используют камунду для построения
> саги, встраивают ее в синхронную обработку
> http запросов, пытаются строить low latency
> приложения.

Для понимания: Вы имеете в виду процесс вроде отображения доступных рейсов в вебе?

То есть: Пользователь вводит в форме, что хочет полететь из Москвы в Петербург 15-го июня. Запускается процесс, в котором сначала опрашиваются все системы бронирования. Каждая из них выдает перечень рейсов разных авикомпаний (допустим, Сейбр выдает рейсы Аэрофлота, а Амадеус -- AirBaltic). За каждым квадратиком скрывается своя, особая логика взаимодействия с каждой системой бронирования (в случае с Сейбром квадратик скрывает еще и боль Галактуса, см. https://youtu.be/y8OnoxKotPQ ).

Когда все системы бронирования ответили, формируется общий список рейсов с данными для веба. Этот список сортируется, допустим, по цене.

Когда все готово, список рейсов отображается в вебе.

Пока идет выгрузка рейсов и сортировка, пользователь ждет.

Камунда нужна, кроме всего прочего, для того, чтобы легче было понимать и отлаживать процессы взаимодействия с системами бронирования.

Вы имеете в виду такой сценарий, когда говорите про low-latency приложения?

В идеале... если использовать например webservices канал... то вообще можно по мере ответа от каждой подсистемы бронирования активно слать данные в веб и отображать по тригерам пришедшим на веб клиенте. Тогда даже задержка будет не общая на все, а отдальная от каждой task

И подобный кейс я тоже встречал. + сверху SLA на ответ

Максим @serg_dat Спасибо.

Не  без шуток. я видел кейс когда пытались камунду прикрутить непосредственно к контроллеру спринг бута и запуская процесс хотели на выходе заполненную DTO получить

ну я прорабатывал технологию с вебом... как пилот... когда на старт формы... просто запускался процесс... а потом события от веб клиента слались в камунду как events, которые обрабатывались текущим процессом... и потом отсылали результаты назад пролвигаясь по процессу, или возвращась обратно... там есть ньансы...

1. Отклики получались от 100ms что в принципе было терпимо...