Находимся в поиске подходящего WorkFlow решения для нового .NET (Web Portal) решения.
Прекрасно подошел бы Microsoft облачный Power Automate, но клиент упёрся всем чем может и настаивает на выделенном серверном решении.
Мы много каких кандидатов нарыли, но явного лидера не нашли.
Посоветуйте чего-то, у кого есть практический опыт.
Наши пожелания следующие (список в случайном порядке):
— Выходы зависят от текущего состояния и входов (машина Мили, если не ошибаюсь)
— Состояния сохраняются в базе (MSSQL)
— Графическое моделирование
— OPTIONAL: переходы декларируются в таблице переходов в базе
— Смена состояния может в т.ч. и внешние функции вызывать (отсылка E-Mail к примеру)
— Async работа
— Динамические invoke — т.е. при изменениях WorkFlow не требуется каждый раз перекомпилировать
— OPTIONAL: Возможность в любой момент запросить список разрешенных actions для конкретного объекта
— Процессы будут "обрываться" и переходить в режим ожидания информации из вне или реакции другого пользователя на другом компьютере
Платформа — последние .NET Core библиотеки: WebAPI, Entity Framework
Здравствуйте, Yuri Abele, Вы писали:
YA>Всем привет!
YA>Находимся в поиске подходящего WorkFlow решения для нового .NET (Web Portal) решения. YA>Прекрасно подошел бы Microsoft облачный Power Automate, но клиент упёрся всем чем может и настаивает на выделенном серверном решении. YA>Мы много каких кандидатов нарыли, но явного лидера не нашли. YA>Посоветуйте чего-то, у кого есть практический опыт.
YA>Наши пожелания следующие (список в случайном порядке): YA>- Выходы зависят от текущего состояния и входов (машина Мили, если не ошибаюсь) YA>- Состояния сохраняются в базе (MSSQL) YA>- Графическое моделирование YA>- OPTIONAL: переходы декларируются в таблице переходов в базе YA>- Смена состояния может в т.ч. и внешние функции вызывать (отсылка E-Mail к примеру) YA>- Async работа YA>- Динамические invoke — т.е. при изменениях WorkFlow не требуется каждый раз перекомпилировать YA>- OPTIONAL: Возможность в любой момент запросить список разрешенных actions для конкретного объекта YA>- Процессы будут "обрываться" и переходить в режим ожидания информации из вне или реакции другого пользователя на другом компьютере
YA>Платформа — последние .NET Core библиотеки: WebAPI, Entity Framework
Здравствуйте, Yuri Abele, Вы писали:
YA>Здравствуйте, gandjustas, Вы писали:
G>>Посмотрите Orchard Core, там все есть. YA>CMS?
Да
YA>Мне стоило добавить, что это Single Page Application — WebAPI + Angular.
Это не помешает использовать Orchard Core
Здравствуйте, Yuri Abele, Вы писали:
YA>Посоветуйте чего-то, у кого есть практический опыт.
Мы перебрали целую пачку, остановились на Workflow.Core, который пришлось основательно допиливать. Основная проблема — с перфомансом у популярных движков типа flowable или comunda все очень печально, целевые 300 wf/s на одной ноде не смог никто даже близко.
YA>- Выходы зависят от текущего состояния и входов (машина Мили, если не ошибаюсь) YA>- Состояния сохраняются в базе (MSSQL) YA>- Графическое моделирование YA>- OPTIONAL: переходы декларируются в таблице переходов в базе YA>- Смена состояния может в т.ч. и внешние функции вызывать (отсылка E-Mail к примеру) YA>- Async работа YA>- Динамические invoke — т.е. при изменениях WorkFlow не требуется каждый раз перекомпилировать YA>- OPTIONAL: Возможность в любой момент запросить список разрешенных actions для конкретного объекта YA>- Процессы будут "обрываться" и переходить в режим ожидания информации из вне или реакции другого пользователя на другом компьютере
Чуть менее чем все движки этому соответствуют. Ну кроме графического моделирования.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Yuri Abele, Вы писали:
НС>Мы перебрали целую пачку, остановились на Workflow.Core, который пришлось основательно допиливать. Основная проблема — с перфомансом у популярных движков типа flowable или comunda все очень печально, целевые 300 wf/s на одной ноде не смог никто даже близко.
А чего не именно не хватило, что именно пришлось допиливать?
И более общий вопрос — а нужен-ли вообще этот движок, не проще было самим реализовать требуемый функционал?
Здравствуйте, swimmers, Вы писали:
НС>>Мы перебрали целую пачку, остановились на Workflow.Core, который пришлось основательно допиливать. Основная проблема — с перфомансом у популярных движков типа flowable или comunda все очень печально, целевые 300 wf/s на одной ноде не смог никто даже близко. S>А чего не именно не хватило, что именно пришлось допиливать?
Я же написал, перфоманса.
S>И более общий вопрос — а нужен-ли вообще этот движок, не проще было самим реализовать требуемый функционал?
Зависит от твоих требований и ограничений по срокам.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Мы перебрали целую пачку, остановились на Workflow.Core, который пришлось основательно допиливать. Основная проблема — с перфомансом у популярных движков типа flowable или comunda все очень печально, целевые 300 wf/s на одной ноде не смог никто даже близко. S>>А чего не именно не хватило, что именно пришлось допиливать? НС>Я же написал, перфоманса.
Сформулировано неоднозначно, не так понял.
А где там тормоза, в сохранении/чтении состояний БД, или еще где-то?
У вас свой форк или вы поделились улучшениями с автором? S>>И более общий вопрос — а нужен-ли вообще этот движок, не проще было самим реализовать требуемый функционал? НС>Зависит от твоих требований и ограничений по срокам.
Сам пока не понимаю про требования))), ну а срок от 3 до 6 месяцев.
Здравствуйте, swimmers, Вы писали:
S>Сформулировано неоднозначно, не так понял.
В основном тормозят внутренние очереди при большой параллельной нагрузке — много кривых блокировок, дедлоки.
S>У вас свой форк или вы поделились улучшениями с автором?
Ты про Workflow.Core? Автор там не особо дружелюбен к внешним правкам. Мелкие багфиксы еще принимает, а вот какие то существенныве изменения — без шансов. У него свое видение архитектуры, которое он обсуждать не хочет.
S>>>И более общий вопрос — а нужен-ли вообще этот движок, не проще было самим реализовать требуемый функционал? НС>>Зависит от твоих требований и ограничений по срокам. S>Сам пока не понимаю про требования))), ну а срок от 3 до 6 месяцев.
Это мало о чем говорит. Если у тебя есть возможность потратить несколько человекомесяцев на свой движок — вперед. У нас — не было. Нам нужно было MVP чуть ли не через пару месяцев выдать. Сейчас продукт уже зарелизен и со сроками попроще, но пока есть куча вещей, которые требуют внимания перед тем как переписывать WF движок.
