- by AJ
Somewhat similar to this question, except we haven't decided that we're going with WF yet.
I'm working on designing a system that requires a series of decisions and activities on a "work object," so I naturally began to consider workflow, specifically WF. What I'm wondering is if WF is a good solution for a situation like the following (oversimplified for this question) case (please forgive bad ascii art):
__________________
| Gather some info |
| (web page) |
|__________________|
|
|
/ \
/ \
/ \
/ \
/ cond \
\ 1 /
\ /
\ /
\ /
\ /
|
|
______________|_______________
| |
| |
| ______|______
______|________ / do some /
| Get more info | / process /
| (web page) | /____________/
|_______________|
|
|
/ \
/ \
/ \
/ cond. \
\ 2 /
\ /
\ /
\ /
|
|
|__________________
| |
| |
_____|_____ _____|_____
/ some / / another /
/ process / / process /
/__________/ /__________/
The part I'm struggling with is the get more info (web page) step and what happens subsequent, which would mean a halt in the execution of the workflow runtime. I'm aware that this is possible, but I'm not sure that WF is the best approach for this type of code, as the user interaction may be required at many different points through the entire workflow, and the workflow will drive what data entry screens are needed. We are using a WinForms/ASP.NET web forms package for UI, which is homegrown and difficult to push deployments on, so something like SharePoint integration is out of the question. Our back-end is DB2, and the workflow code (whether it's in WF or otherwise) will need to interact with that as well.
I guess the bottom line is, should we look into using WF for this, or would we be better served just coding it ourselves? Can WF easily integrate data entry screens to capture information that can be used further on in the workflow?
