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开发者_StackOverflow社区 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?
Using WF's long-running workflow capability, I believe it would work. Your workflow can persist to a database at any time. If there are several conditional forms to be filled out, include their definition as steps in the workflow (there are many ways to approach this.) This way, the workflow drives not only the process but the request for data.
When the workflow is persisted, it could be "woken up" by a user going to continue work on that workflow. The application (ASP.NET, Winforms, whatever) can query the workflow to find out what abstracted "form" to present.
精彩评论