Is it better to have one big workflow or several smaller specific ones?

Question

I need to build an app that gets files from a server and moves to another server. It was suggested that I look into using Windows Workflow Foundation (WF).

I started to build the workflow but it is getting messy and I'm not sure I'm doing it the best way possible.

Here is the basic worklow activities:

Get a list of sources Determine if source is ftp or disk drive Get a list of files from the server If source is ftp then get the file with ftp get else if source is drive then read file from drive If target is ftp then ftp file to server else if target is drive then write to a drive else if target is web service then post to web service If source is ftp then delete file with ftp commands else if source is drive then delete file

With one workflow it gets a little busy. I need 2 while loops, one around the integrations and one after I get a file list.

The other thing I thought of was to build multiple workflows. One for FTPtoFTP, FTPtoDrive, FTPtoWebServie, DriveToFTP, DrivetoDrive, DriveToWebService.

Any suggestions?

Answer 1

Well personally I have not used WWF yet. I have done quite a bit of workflows before though. To me breaking them up into smaller workflows would seem to be the best way. When you're working with workflows you should try to limit each workflow to a specific task so that you have a definitive start action and at least one successful route and at least one failure route. Workflows in general can be very tricky things and it's best to keep each as simple as possible.

Answer 2

As a general rule, anytime things get "messy", you should break them down into smaller parts. I'd definitely recommend breaking it down into several workflows.

Answer 3

First, you should consider creating custom Activities for each of the major sections. The custom activities will be Composite Activities that can be composed of many steps. This will help de-clutter things a bit and allow you to continue working with the workflows at a relatively high-level.

The Workflow Designer, while handy, is not really designed to scale very large. As of VS 2008, the best way to work with XAML-based technologies is to use the text editor and read/write the XML directly.

Breaking it down into several workflows might not be the best approach unless you can break it down into a few high-level activities and are working at the XAML level. Keep in mind that if the logic and flow is nearly identical for all of these, you will now have to maintain 6 different workflows. This is a bigger nightmare if your workflows are complex and you need to fix a common logic error across all of them.

You should also consider the use of the Services. This may allow you to have ONE workflow and ONE set of activities, but the implementation of each step can be isolated into a service. In this case, you would need to instantiate one workflow per combination, load the same workflow into each, and inject different activities. Not necessarily the best approach, but something to consider.

Answer 4

First of all, this sounds to me like using WF is adding extra complications to what should be a fairly straightforward process. Although WF can be used to model execution flow, its purpose is to model business flow, and include business rules and logic without putting those into your implementations.

In your example, the business rules seem largely like things which should be dealt with by an app.config file.

However, on the broader question of using one workflow or many. You want each of your workflow tasks to be approximately the same 'broad scope'

For instance WF for building a table

• purchase wood
• cut wood
• cut wood for legs
• bevel edges
• round cornices
• sand twice with different coarseness
• assemble table

The steps in the middle are all much more detailed than the steps around them. So you would consider splitting it up into two separate workflows: a high level workflow that contains the broads steps, and lower level workflows that contain the particulars.

So the 'GetDatasource' workflow step would not care (externally) what type of datasource it is gathering from, it just returns to the next step in the workflow a set of data.

Same goes for target, it doesn't care what type of datasource it had, it only cares what it has to do with the data. So that should be encapsulated as well.

So your Workflow could be three workflows

Highest WF

1. GetDataSourceWF
2. DoThingsWithDataWF

Then your DoThingsWithDataWF and GetDataSourceWF Workflows can each be concerned with only the execution context that they need.

EDIT

As pointed out by the commenter James Schek. You can use the higher level workflow to actually kick off your lower level workflows and manage their execution into each other.