Создание User-Friendly движка бизнес-процессов на основе Windows Workflow Foundation

[Hydro]

Откуда брали информацию по конвертации уже запущенных в работу инстансов?

[lsreg]

http://msdn.microsoft.com/en-us/library/hh314052(v=vs.110).aspx
https://code.msdn.microsoft.com/An-Introduction-to-Dynamic-01304b61

[sergeevms]

Что использовалось раньше в качестве движка для workflow? В какой версии произошел (или пока не произошел) переход? Чем не устраивал «старый»? Потребителю (пользователю системы) переход на новый движок что-то даст?

[lsreg]

Сейчас используется самописный движок.
Движок на WF — лабораторное решение, до продакшена пока не дошел.

[Scogun]

Три года мучились с WF (правда для .Net 3.5). Основной проблемой — была невозможность менять маршрут без deploy (система используется 24/7). Ну, и несколько других меньших. В результате, за пару месяцев изобрели велосипед, на который не нарадуемся. Однако, в любом случае, тема все же интересная.

[imanushin]

Абсолютно аналогичная история. У WF к тому же есть четкое ограничение производительности, на которое можно достаточно быстро наткнуться.

[Scogun]

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

[imanushin]

После прочтения статьи может создаться впечатление, что мы зря использовали Workflow Foundation – это не так. Благодаря использованию WF мы получили из коробки хостинг, хранение экземпляров процессов, всю логику выполнения процессов, в том числе и параллельного.

А можете рассказать, какая у Вас нагрузка на систему? И сколько лет она уже живет? Ведь эти модули в Workflow сделаны далеко не самым лучшим образом.
Просто по пунктам:

• хостинг — что здесь имеется ввиду? Workflow запускается после метода StartRuntime. Функция получения сообщения сводится к простейшим действиям: забрать объект из базы, десериализовать его, найти структуру, которая относится к Activity, вызвать у неё метод, <Ваша бизнес-логика>, сериализовать состояние, сохранить данные в БД. Не так много работы, если в итоге Вы получаете полностью подконтрольное поддерживаемое решение..
• хранение экземпляров процессов — дело в том, что эта система работает не слишком эффективно. Если у Вас будет расти нагрузка, то Вам придется её переделывать.
• «всю логику выполнения процессов, в том числе и параллельного» — а логика простая: блокируем Instance, выполняем у него последовательно все задачи, которые требуется, сохраняем его. Внутри одного Workflow Instance кооперативная многозадачность, сложного здесь ничего нет.

Вы можете увидеть комментарии выше — Workflow Runtime неоднократно уже переписывался разными людьми, причем общая причина одна: что-то работает не так, как требуется, а код менять нельзя. Просто, скорее всего, Вам придется заняться этим в дальнейшем. Получается, что Workflow для Вас — это временное решение, чтобы побыстрее сделать релиз, а дальше продолжать уже создавать своё, заменяя классы MS.

[lsreg]

Выше уже писал, что движок пока не используется в продакшене. На тестах проблем с производительностью не было.
В СЭД бизнес-процессы долгоиграющие и нет разницы, отработает WF за 10 миллисекунд или 10 секунд.

Насчет переписывания — возможно потом мы и доберемся до ограничений WF, пока нас все устраивает.

[nzeemin]

Когда-то имел опыт работы со Staffware — уже отживший своё workflow движок. Так вот там workitem из состояния в состояние мог переходить и минут 10-15, без видимых причин. Но зато движок мог обрабатывать одновременно миллионы workitems.