Comments 11
Откуда брали информацию по конвертации уже запущенных в работу инстансов?
Что использовалось раньше в качестве движка для workflow? В какой версии произошел (или пока не произошел) переход? Чем не устраивал «старый»? Потребителю (пользователю системы) переход на новый движок что-то даст?
Три года мучились с WF (правда для .Net 3.5). Основной проблемой — была невозможность менять маршрут без deploy (система используется 24/7). Ну, и несколько других меньших. В результате, за пару месяцев изобрели велосипед, на который не нарадуемся. Однако, в любом случае, тема все же интересная.
Абсолютно аналогичная история. У WF к тому же есть четкое ограничение производительности, на которое можно достаточно быстро наткнуться.
Да, с десериализацией тоже были проблемы, правда смогли их обойти без выноса кода: при невозможности десериализации, движок убивал старые данные и создавал уже новый объект, переводя его в последнее состояние старого. Однако для нормальной работы пришлось некоторые данные дублировать в обычных таблицах.
После прочтения статьи может создаться впечатление, что мы зря использовали Workflow Foundation – это не так. Благодаря использованию WF мы получили из коробки хостинг, хранение экземпляров процессов, всю логику выполнения процессов, в том числе и параллельного.
А можете рассказать, какая у Вас нагрузка на систему? И сколько лет она уже живет? Ведь эти модули в Workflow сделаны далеко не самым лучшим образом.
Просто по пунктам:
- хостинг — что здесь имеется ввиду? Workflow запускается после метода StartRuntime. Функция получения сообщения сводится к простейшим действиям: забрать объект из базы, десериализовать его, найти структуру, которая относится к Activity, вызвать у неё метод, <Ваша бизнес-логика>, сериализовать состояние, сохранить данные в БД. Не так много работы, если в итоге Вы получаете полностью подконтрольное поддерживаемое решение..
- хранение экземпляров процессов — дело в том, что эта система работает не слишком эффективно. Если у Вас будет расти нагрузка, то Вам придется её переделывать.
- «всю логику выполнения процессов, в том числе и параллельного» — а логика простая: блокируем Instance, выполняем у него последовательно все задачи, которые требуется, сохраняем его. Внутри одного Workflow Instance кооперативная многозадачность, сложного здесь ничего нет.
Вы можете увидеть комментарии выше — Workflow Runtime неоднократно уже переписывался разными людьми, причем общая причина одна: что-то работает не так, как требуется, а код менять нельзя. Просто, скорее всего, Вам придется заняться этим в дальнейшем. Получается, что Workflow для Вас — это временное решение, чтобы побыстрее сделать релиз, а дальше продолжать уже создавать своё, заменяя классы MS.
Выше уже писал, что движок пока не используется в продакшене. На тестах проблем с производительностью не было.
В СЭД бизнес-процессы долгоиграющие и нет разницы, отработает WF за 10 миллисекунд или 10 секунд.
Насчет переписывания — возможно потом мы и доберемся до ограничений WF, пока нас все устраивает.
В СЭД бизнес-процессы долгоиграющие и нет разницы, отработает WF за 10 миллисекунд или 10 секунд.
Насчет переписывания — возможно потом мы и доберемся до ограничений WF, пока нас все устраивает.
UFO just landed and posted this here
Sign up to leave a comment.
Создание User-Friendly движка бизнес-процессов на основе Windows Workflow Foundation