В Вашем случае нагрузка сравнительно небольшая, выдержит практически любой движок. Вопрос в истории и сложности бизнес-процессов. В случае транзакционных bpmn, требуется сразу подумать об очистке (полной или частичной) истории. Лично я, видя Ваши показатели по нагрузке, выбрал бы Zeebe (Camunda Platform). Во-первых сразу заложиться на развитие системы, во-вторых - проект живой, регулярно улучшается и обновляется, в третьих - используются передовые, на данный момент, технологии и интеграционные решения. Если же нужно быстрое решение (завтра в прод), то, видимо, Camunda 7.X (но быть готовым, что поддержка проекта заканчивается и нужно думать о периодических чистках и оптимизации бд). In-memory бд, в Вашем случае пока не имеет смысла.
Мы в проде, обновились до 8й версии. Сам движок Zeebe стал стабильнее, улучшается от версии к версии. От нативного DMN от Camunda пришлось отказаться, нам нужно быстрее, написали свой совместимый по-проще. Так же сделали свой фронт с редактором BPMN, DMN, упрощенный Optimize и пользовательские задачи. Пока довольны.
Подскажите, пожалуйста, предполагается ли в будущем какая-то визуальная часть - фронт? Основным достоинством Camunda, Zeebe является возможность нарисовать процесс, согласовать его с бизнесом, а потом в сockpit увидеть визуально, где находится процесс, где ошибки, просматривать контекст и многое другое. Если основная задача была в декомпозиции, не смотрели ли на существующие аналоги - Spring Integration, Apache Camel ?
Спасибо большое за статью! Вы пишете про SAP, что "большая база данных требует десятков терабайтов оперативной памяти". Подскажите, пожалуйста, на какое ориентировочное кол-во пользователей рассчитаны столь невероятные ресурсы? Какую примерную конфигурацию серверов 1С можно сопоставить, чтобы справится с аналогичной нагрузкой?
Flowable обогнал только Zeebe. Результаты хуже, чем у Camunda примерно в 2 раза. Без экспорта результат проигрывает Camunda почти в 4 раза. Код проекта добавил к существующей группе проектов - pure-flowable.
Спасибо за комментарий! Flowable хороший фреймворк, у них с Camunda общий предок Activity. Flowable даже более поздний форк. К сожалению, не взял в обзор, у меня нет примеров из банков его использования. А Ваша компания его использует?
Если для Вас актуально, то для подписки на события завершения процесса можно добавить свой обработчик исторических событий. Для этого можно получить ProcessEngine и добавить обработчик в его конфигурацию: SpringProcessEngineConfiguration config = (SpringProcessEngineConfiguration) processEngine.getProcessEngineConfiguration();
Согласен, инструмент пока новый, помню, что и к Camunda сначала относились осторожно, предпочитая проверенный годами IBM BPM. Сейчас Camunda уже крепко стоит на ногах и является важным компонентом многих банков. Уверен, что и у ZeeBe большее будущее!
Нам еще предстоит очень большая работа, чтобы выйти в прод, нужно переделать из текущего монолита очень много интеграций (на spring integraion), постараемся успеть к концу года. Пока обкатываем прототип на среде dev и то что получается, работает вполне стабильно.
Отличный вопрос, хотя и action-ы кажутся независимыми друг от друга, они связаны между собой переменными процесса и, отчасти, зависят друг от друга, в том числе и в разработке / тестировании. В другом проекте была подобная схема с большим количеством external task-ов, 8-10 backend разработчиков. Нам с коллегами удавалось распределять задачи по разработке action-ов, чтобы выходить примерно в одно и то же время на test/prod. Есть положительный опыт использования Asciidoctor (с указанием входных и выходных переменных от которых action будет зависеть) вместе с тестами для документирования action-ов внутри микросервисов. С апгрейдом здесь немного лучше, чем в Camunda, процессы летят быстро и можно не так сильно концентрироваться на обратной совместимости из-за большого количество уже запущенных процессов.
Наша цель приблизиться к примерно 40 процессов в секунду (потребности бизнеса). Пока ограничены в железе на деве, в нагрузочном тестировании запускал порядка 15 процессов в секунду.
В Вашем случае нагрузка сравнительно небольшая, выдержит практически любой движок. Вопрос в истории и сложности бизнес-процессов. В случае транзакционных bpmn, требуется сразу подумать об очистке (полной или частичной) истории.
Лично я, видя Ваши показатели по нагрузке, выбрал бы Zeebe (Camunda Platform). Во-первых сразу заложиться на развитие системы, во-вторых - проект живой, регулярно улучшается и обновляется, в третьих - используются передовые, на данный момент, технологии и интеграционные решения. Если же нужно быстрое решение (завтра в прод), то, видимо, Camunda 7.X (но быть готовым, что поддержка проекта заканчивается и нужно думать о периодических чистках и оптимизации бд). In-memory бд, в Вашем случае пока не имеет смысла.
Мы в проде, обновились до 8й версии. Сам движок Zeebe стал стабильнее, улучшается от версии к версии. От нативного DMN от Camunda пришлось отказаться, нам нужно быстрее, написали свой совместимый по-проще. Так же сделали свой фронт с редактором BPMN, DMN, упрощенный Optimize и пользовательские задачи. Пока довольны.
Подскажите, пожалуйста, предполагается ли в будущем какая-то визуальная часть - фронт? Основным достоинством Camunda, Zeebe является возможность нарисовать процесс, согласовать его с бизнесом, а потом в сockpit увидеть визуально, где находится процесс, где ошибки, просматривать контекст и многое другое. Если основная задача была в декомпозиции, не смотрели ли на существующие аналоги - Spring Integration, Apache Camel ?
Спасибо большое за статью! Вы пишете про SAP, что "большая база данных требует десятков терабайтов оперативной памяти". Подскажите, пожалуйста, на какое ориентировочное кол-во пользователей рассчитаны столь невероятные ресурсы? Какую примерную конфигурацию серверов 1С можно сопоставить, чтобы справится с аналогичной нагрузкой?
Flowable обогнал только Zeebe. Результаты хуже, чем у Camunda примерно в 2 раза. Без экспорта результат проигрывает Camunda почти в 4 раза. Код проекта добавил к существующей группе проектов - pure-flowable.
Спасибо за комментарий! Flowable хороший фреймворк, у них с Camunda общий предок Activity. Flowable даже более поздний форк. К сожалению, не взял в обзор, у меня нет примеров из банков его использования. А Ваша компания его использует?
Спасибо большое за интересную статью про Camunda!
Если для Вас актуально, то для подписки на события завершения процесса можно добавить свой обработчик исторических событий. Для этого можно получить ProcessEngine и добавить обработчик в его конфигурацию:
SpringProcessEngineConfiguration config = (SpringProcessEngineConfiguration) processEngine.getProcessEngineConfiguration();config.setHistoryEventHandler(new HistoryEventHandler() {@Overridepublic void handleEvent(HistoryEvent historyEvent) {if (HistoricProcessInstanceEventEntity.class.equals(historyEvent.getClass()) && "end".equals(historyEvent.getEventType())) {// Событие окончания инстанса процесса } } .. }});Нам еще предстоит очень большая работа, чтобы выйти в прод, нужно переделать из текущего монолита очень много интеграций (на spring integraion), постараемся успеть к концу года. Пока обкатываем прототип на среде dev и то что получается, работает вполне стабильно.