Workflow In Production Code

Question

Hi I would like to know how many of you have used Workflow in your production environment and Was it good idea? I mean we can create the same thing using DB and scheduler service

Answer 1

We use WF in our production enviorments. We have 6 different workflows that can be run. These split into 3 statemachine and 3 sequences. I would use it again in some circumstances, but I would not in others. I would claim that the statemachine part of the workflow was tacked on the end quickly, I'm not sure it a core part of the workflow all the way through design.

I would use workflow again for short running processes like quotes or transforming things before sending them to supliers that kind of thing.

I would not want to do it again for a long running statemachine - mainly because there is not a built in WF upgrade process so we ended up writing our own. There are also a lot of concepts to get your head around (affectionalty known as gypsy curses with in our development team).

I would also be slightly concerned about performance: our App server is currently running flat out (ok I am restarting 8000 workflows at the moment). This is especially a problem if you integrate it directly into WCF using the (.NET 3.5) send and recieve activities - there are some properly crazy config settings you have to set to allow it run multiple workflows at once.

Anyway, as I said: it is useful, I would use it again, but not for another statemachine.

Also see Please confirm: Is Windows Workflow Foundation a good horse to be backing right now?

Answer 2

We use Sharepoint, which uses WF for its workflows. It works pretty well and is fairly easy to customize. If you need an advanced workflow, WF can support it but it will take some training to learn the ins and outs.

You could roll your own workflow, but why reinvent the wheel? WF is built into the .NET 3.0+ framework and is pretty robust, so you might as well take advantage of it.