Успешно ли вы приняли Windows Workflow в реальном веб-приложении?

Question

Недавно я опубликовал вопрос о рабочем процессе Windows, работающем в веб-приложении. Конечно, это был довольно технический вопрос, в котором содержались такие термины, как ManualWorkflowSchedulerService, HandleExtrenalEvent и т. Д., За 20 дней он получил около 15 просмотров.

Хотя я, скорее всего, не правильно задал вопрос, это заставило меня задуматься о принятии рабочего процесса Windows в реальных приложениях, особенно в веб-приложениях.

Успешно ли вы внедрили реальные интернет-приложения с WF и оглядываясь назад, окупили ли вложения ваших денег (времени)?

Answer 1

Мы используем рабочий процесс конечного автомата для управления несколькими процессами запросов на обслуживание, каждый из которых содержит около 10 состояний. Я не уверен, что это был правильный выбор на 100%, потому что реализация простого конечного автомата была бы проще (возможно, мы пострадали здесь от BDUF).

Самым большим недостатком для нас была кривая обучения. Я имею в виду, что рабочий процесс - это практически урезанная версия biztalk (бесплатно!).

Сверху моей головы, вот области, которые мы получили от WF:

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

Я всегда стараюсь помнить, что это действительно фундамент. Как разработчик / архитектор, вы должны посвятить себя созданию чего-то полезного.

Answer 2

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

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

Answer 3

привет Том, я действительно не думаю, что WF хорошо работает, когда мы используем веб-приложения, потому что, скорее всего, мы будем использовать БД для сохранения состояния, вы точно задали вопрос, который у меня был на уме мы использовали WF в нашей производственной среде, и это создает массу проблем при переходе с одной версии на другую. во-вторых, имеет множество ограничений, то есть не поддерживает транзакции я думаю, что нам следует подождать версии 4 или 5, чтобы узнать, может ли она предложить что-то лучшее

Answer 4

Я развернул 3 приложения. 2 являются приложениями ASP.NET, а 1 рабочий процесс был развернут в среде SharePoint. Оглядываясь назад, я думаю, что инвестиции стоили того. Как сказал предыдущий парень, WF - это фреймворк, на котором вы должны опираться. Это еще один слой для беспокойства, но выгоды перевешивают затраты.

Answer 5

Мой опыт был аналогичен Out Into Space, мы рассматривали использование WF для управления сложным и разнообразным процессом заказа в различных сценариях B2B. Последнее, что я слышал, они были в процессе потрошения.

Я думаю, что многим разработчикам трудно думать с точки зрения рабочего процесса.