Workflowengine или BP-Engine для C#/.NET

Question

Я надеюсь, что мой вопрос не слишком "не по теме" ... тем не менее я много искал в последние дни и не смог найти решение своей проблемы.

В этом месяце я начал работать над своей магистерской работой. Тезис. Для этого мне нужно интегрировать рабочий процесс в существующий программный пакет (5+ компонентов + шинная система). Workflow-Engine должен иметь возможность запускать операции / задачи внутри компонентов, и он должен иметь возможность взаимодействия компонентов с механизмом (триггерные переходы, установки состояний...). Одна из ключевых проблем заключается в том, что программный пакет и дополнительная архитектура шины написаны на C#. Поэтому было бы неплохо, если бы сам движок был частью технологии C#/.Net, а не Java (требуется развертывание JVM и обновления, и так далее...)

Что я ищу

• Рабочий процесс или BP-Engine для C#/.NET
• возможность взаимодействия с движком из программного обеспечения (других API) (в обоих направлениях - вход и выход)
• Управление версиями обязательно
• Открытый исходный код (бесплатный) или коммерческий не важен
• определение рабочих процессов в коде не требуется
• BPMN 2.0 или другое графическое моделирование это хорошо, но не обязательно (XML хорошо)
• специальный конструктор форм не требуется (компоненты принимают участие в этой части)

Пока у меня есть три возможных двигателя на выбор

1. Windows WF

Я прочитал много плохих вещей о MS WF. Особенно мне не нравится, что информация хранится в простой двоичной форме. Насколько я вижу, управление версиями не является ключевой особенностью WF. Но я не вижу проблем или ошибок для интеграции, потому что это "низкий уровень".

2. WorkflowEngine.NET

Workflow Engine.NET выглядит интересно, но управление версиями здесь тоже не главное. Кроме того, я не знаю, позволяет ли это мне использовать другие API, такие как шинная система.

3. Бизаги

Мой нынешний фаворит. Он поддерживает другие API и доступен для.Net. Но опять же я не нашел полезной информации о версиях.

Кто-нибудь из вас раньше работал с одним или несколькими из этих движков и может предоставить информацию об использовании движка и сложности их интеграции? Существуют ли другие / лучшие рабочие процессы для моих нужд? Или вы бы посоветовали написать мой собственный движок (не моя любимая идея)?

с уважением

Alex

Answer 1

Взгляните на Slickflow . это проект с открытым исходным кодом, основанный на .NET5; Продукт движка легко использовать в кроссплатформенном приложении. Slickflow использует нотацию BPMN для описания диаграммы процесса, конструктор Slickflow - это редактор графиков HTML5, удобный для взаимодействия с бизнес-процессами и бизнес-анализа. Slickflow поддерживает SQLSERVER, ORACLE, MySQL и другую базу данных, реализованную библиотекой расширений Dapper.NET. Версия ядра .net, использующая ядро ​​EF для поддержки различных продуктов баз данных.

вы можете посмотреть «Учебное пособие по быстрому запуску Slickflow», которое может вам помочь

см. демонстрацию: http://demo.slickflow.com/sfd/

Answer 2

Посмотрите на https://workflowengine.io/. Он имеет версию.NET, имеет версионность и обеспечивает взаимодействие In/Out с вашим собственным решением и другим сторонним программным обеспечением.

Answer 3

Определенно не по теме для SO, но, имея больше опыта, чем хотелось бы, с Windows WF4, я решил, что опубликую.

Управление версиями в WF может означать разные вещи для разных людей. WF не имеет встроенного управления версиями, потому что это в первую очередь механизм выполнения - вы должны предоставить ему то, что хотите запустить, и поэтому отвечаете за управление версиями.

Для кратковременных рабочих процессов это тривиально: вы ведете журнал всех версий рабочего процесса, и пользователь может выбрать одну из них как «развернутую». Когда наступает запускающее событие, вы передаете WF "развернутый" Activity и он бежит.

Для долговечных рабочих процессов вы должны принимать дизайнерское решение, основываясь на компетенции ваших пользователей. Если вы считаете, что они могут вносить изменения, которые не нарушают структуру и состояние выполняемого рабочего процесса, вы можете выполнять обновления рабочих процессов «на лету», передавая новую версию в событии возобновления. Поскольку вы исключаете возможность кодированных рабочих процессов, я предполагаю, что вы ориентируетесь на менее квалифицированного менеджера рабочих процессов. Это больше относится ко второму варианту, который должен записывать с каждым экземпляром рабочего процесса версию, которая была развернута во время инициирующего события. Когда появится резюме, передайте ему старую версию.

В большинстве случаев модель одновременного выполнения нескольких версий рабочего процесса в течение короткого периода не вызывает затруднений. Это в значительной степени отражает реалии обычного бизнеса (требуется время, чтобы переобучиться, распространить новые формы, обновить системы и т. Д.).

В некоторых случаях, однако, вы не можете ни ожидать технической компетентности, ни разрешать более старым версиям продолжать работу (например, ошибка, приводящая к заниженной стоимости клиента). В этом случае становится критически важным, чтобы рабочие процессы были спроектированы так, чтобы быть в некоторой степени идемпотентными, чтобы вы могли завершить экземпляры выполнения любых старых версий рабочего процесса и повторно запустить их в новой версии.

Опять же, эта идемпотентная модель может быть довольно легко объяснена пользователям, поскольку она снова соответствует задачам реального мира. Иногда люди запускают повторяющиеся задачи или возобновляют работу после неудачи другого коллеги. Понятно, что в рамках рабочего процесса необходимо проверять некоторые незавершенные действия.

Answer 4

Workflow Core - это легкий встраиваемый механизм рабочего процесса, ориентированный на .NET Standard. Подумайте: долго выполняющиеся процессы с несколькими задачами, которым необходимо отслеживать состояние. Он поддерживает подключаемые поставщики сохраняемости и параллелизма, что позволяет создавать кластеры с несколькими узлами.

С дирижером:

Conductor - это автономный сервер рабочего процесса, в отличие от библиотеки, которая использует Workflow Core внутри. Он предоставляет API, который позволяет хранить определения рабочих процессов, отслеживать выполняющиеся рабочие процессы, управлять событиями и определять пользовательские шаги и сценарии для использования в ваших рабочих процессах.

Функции:

-Определите свои рабочие процессы с помощью свободного API.

-Определите свои рабочие процессы в JSON или YAML, необходимо установить WorkFlowCore.DSL

- несколько поставщиков сохраняемости, доступных в виде отдельных пакетов Nuget.

MemoryPersistenceProvider (поставщик по умолчанию, для демонстрации и тестирования) - MongoDB-Cosmos DB-Amazon DynamoDB-SQL Server-PostgreSQL-Sqlite-MySQL-Redis